为什么跨建筑约定会将scala版本附加到artifactId？

Question

用于指示针对哪个版本编译库的Scala的基本机制是追加_

虽然这是一种简单的方法，但与Maven和其他构建工具的互操作性还有待改进。因为artifactId是不同的（例如scalatest_2.9.0和scalatest_2.10.0），Maven将它们视为不同的工件。Maven的依赖项解析机制因此受到了损害，同一工件的多个版本（针对不同的scala版本构建）可能会出现在类路径上。

为什么不把scala版本放在分类器中呢？这似乎是分类器的主要预期用途之一：

分类器允许[Maven]区分由相同的POM构建但内容不同的工件。作为这个元素的动机，例如考虑一个项目，该项目提供了一个针对JRE 1.5的工件，但同时也提供了一个仍然支持JRE 1.4的工件。第一个工件可以配备分类器jdk15，第二个工件可以配备jdk14，这样客户端就可以选择使用哪个。--Maven文档：POM参考

Answer 1

在名称后面添加版本是一个历史性的决定，这是很久以前做出的，所以它很可能不会改变，因为许多库已经按照该约定发布了。

话虽如此，正如赛斯所指出的，几年前，sbt 0.12将“_2.10.0”后缀缩短为“_2.10”，以利用Scala库在次要版本之间的二进制兼容性，讨论了这个话题。以下是[0.12]计划中的标记：

所谓交叉版本控制，我指的是在模块ID中包含Scala版本的某些部分，以区分通过编译相同源代码和不同Scala版本生成的工件。我指的不是使用任务构建多个Scala版本的能力，这将持续下去；我指的是跨版本公约。

[剪报]

在不灵活的pom中对其进行编码一直是一个难题。xml格式，我认为对于基于Scala 2.10及更高版本构建的项目，最好不要使用这种格式。然而，这或许比任何可能取代它的临时解决方案都要好。我没有看到其他构建工具的用户这样做，所以我希望没有什么能取代它。

乔希建议说：

（1）Scala分类器。这些可以是自定义字符串，可以通过依赖项指定。至少，IIRC这应该工作。

以下是马克的回应：

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

下面是杰夫·里德关于量词的一些更有趣的评论

我也认为分类器将是处理这个问题的完美方式，尤其是考虑到maven文档中的建议，即使用分类器java-1.4和java-1.5来区分适合各自平台的JAR。致命的缺陷似乎是可传递的依赖关系管理。也就是说，无法根据用于要求模块的分类器来选择可传递依赖集。我们需要能够说，当您将此模块与scala-2.10分类器一起使用时，它会使用scala-2.10分类器带来自己的依赖项，当与2.9分类器一起使用时，它会使用scala-2.9分类器带来自己的DEP。

我认为使用jvm版本可以实现这一点，因为jvm版本控制在配置文件激活中有特殊的支持，可以控制依赖关系。