maven - 为什么交叉构建约定将 scala 版本附加到 artifactId？

Question

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 将它们视为不同的 Artifact 。 Maven 的依赖解析机制因此受到损害，并且同一 Artifact 的多个版本(针对不同的 Scala 版本构建)可能会出现在类路径上。

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

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

Answer 1

将版本附加到名称是很久以前做出的历史决定，因此它可能不会改变，因为许多库已经按照约定发布了。

话虽如此，正如 Seth 所指出的，几年前有一次讨论要回顾这个主题，当时 sbt 0.12 将“_2.10.0”后缀缩短为“_2.10”，以利用 Scala 库在次要版本之间的二进制兼容性。这是来自 [0.12] plan 的马克:

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]

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 suggested :

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

这是马克的 response :

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 的关于分类器的一些更有趣的评论。

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.

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.