为什么跨构建约定将scala版本附加到artifactId? [英] Why does the cross-building convention append the scala version to the artifactId?

问题描述

用于指示对库进行编译的Scala版本的基础机制是在_ 后面附加_ .图书馆的名字.这种相当简单的方法允许与Maven，Ant和其他构建工具的用户互操作. - sbt文档:跨版本发布约定

The underlying mechanism used to indicate which version of Scala a library was compiled against is to append _<scala-version> to the library's name. This fairly simple approach allows interoperability with users of Maven, Ant and other build tools. -- sbt Documentation: Cross-Build Publishing Conventions

虽然这是一种简单的方法，但与Maven和其他构建工具的互操作性仍有待改进.因为artifactId是不同的(例如scalatest_2.9.0和scalatest_2.10.0)，所以Maven将它们视为不同的工件.因此，Maven的依赖关系解析机制受到损害，并且同一工件的多个版本(针对不同的Scala版本构建)可以在类路径上出现.

While this is a simple approach, the interoperability with Maven and other build tools leaves something to be desired. Because the artifactId is different (e.g. scalatest_2.9.0 and scalatest_2.10.0), Maven treats them as different artifacts. Maven's dependency resolution mechanism is thus compromised and multiple versions of the same artifact (built against different scala versions) can wind up on the classpath.

为什么不将scala版本放在分类器中?这似乎是分类器的主要预期用例之一:

Why not put the scala version in the classifier? This seems to be one of the primary intended use cases for the classifier:

分类器允许[Maven]区分由相同POM构建但内容不同的工件.作为对此元素的激励，例如考虑一个提供针对JRE 1.5的工件的项目，同时提供仍然支持JRE 1.4的工件.第一个工件可以配备分类器jdk15，第二个工件可以配备jdk14，以便客户可以选择使用哪个分类器. - Maven文档:POM参考

The classifier allows [Maven] to distinguish artifacts that were built from the same POM but differ in their content. As a motivation for this element, consider for example a project that offers an artifact targeting JRE 1.5 but at the same time also an artifact that still supports JRE 1.4. The first artifact could be equipped with the classifier jdk15 and the second one with jdk14 such that clients can choose which one to use. -- Maven Documentation: POM Reference

推荐答案

在名称上加上版本是一个很久以前的历史决定，因此，由于已经发布了许多约定的库，所以它不会改变

Appending version to the name is a historical decision that was made long time ago so it'll likely not going to change since many libraries are published with the convention already.

正如Seth所言，几年前，sbt 0.12将"_2.10.0"后缀缩短为"_2.10"，以利用Scala库在次要版本之间的二进制兼容性时，进行了讨论以审查此主题.版本.这是 [0.12]计划中的标记:

Having said that, as Seth noted, there was a discussion to review this topic a few years ago when sbt 0.12 shortened "_2.10.0" postfix to "_2.10" to take advantage of Scala library's binary compatibility between the minor versions. Here's Mark from [0.12] plan:

通过交叉版本控制，我的意思是在模块ID中包含Scala版本的某些部分的做法，以区分通过针对不同的Scala版本编译相同的源代码而生成的工件.我并不是说使用+task针对多个Scala版本进行构建的能力，这种能力将继续存在.我指的是跨版本约定.

By cross versioning, I mean the practice of including some part of the Scala version in the module ID to distinguish an artifact generated by compiling the same source code against different Scala versions. I do not mean the ability to build against multiple Scala versions using +task, which will stay; I am just referring to the cross version convention.

[snip]

以不灵活的pom.xml格式进行编码一直是黑客，我认为对于基于Scala 2.10及更高版本构建的项目，最好不要使用此编码.但是，这可能比任何可能采用的临时解决方案要好.我看不到其他构建工具的用户正在执行此操作，因此我希望没有什么可以替代它.

It has always been a hack to encode this in the inflexible pom.xml format and I think it may be best to move away from this for projects built against Scala 2.10 and later. However, perhaps this is better than any ad hoc solutions that might take its place. I don't see users of other build tools doing this, so I expect nothing would replace it.

Josh 建议:

(1)Scala分类器.这些可以是自定义字符串，并且可以用依赖项指定.至少，IIRC应该可以.

(1) Scala classifiers. These can be custom strings and can be specified with dependencies. At least, IIRC this should work.

以下是马克的响应:

可以指定依赖项"是什么意思?所有分类器只有一个pom，对吗?您如何为每个分类器声明不同的依存关系?

What do mean by "can be specified with dependencies"? There is only one pom for all of the classifiers, right? How can you declare different dependencies for each classifier?

关于 Geoff Reedy 的分类器，这里有一些更有趣的评论. >

Here are some more interesting remark on classifiers from Geoff Reedy

我也认为分类器将是应对的完美方式 尤其是考虑到Maven文档中的建议，该问题 分类器java-1.4和java-1.5用于区分jars 适用于各自的平台.致命的缺陷似乎是 传递依赖管理.也就是说，无法选择 基于用于要求 模块.我们需要能够说的是，当您使用此模块时 通过scala-2.10分类器，它使用 scala-2.10分类器，当与2.9分类器一起使用时，会引入 使用scala-2.9分类器自己的部门.

I too thought that classifiers would be the perfect way to deal with this issue especially in light of the suggestion in the maven docs that classifiers java-1.4 and java-1.5 be used to distiguish between jars appropriate for the respective platform. The fatal flaw seems to be transitive dependency management. That is, there's no way to choose the transitive dependency set based on the classifier used to require the module. We'd need to be able to say that when you're using this module with the scala-2.10 classifier it brings its own dependencies using the scala-2.10 classifier and when used with the 2.9 classifier brings in its own deps with the scala-2.9 classifier.

我认为使用jvm版本可以使这项工作可行，因为 jvm版本控制在配置文件激活中具有特殊支持，可以 可以控制依赖性.

I think with the jvm versions it's possible to make this work because jvm versioning has special support in the profile activation which can can control dependencies.

这篇关于为什么跨构建约定将scala版本附加到artifactId?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！