用于指示编译库的Scala版本的基础机制是将_ <scala-version>附加到库的名称.这种相当简单的方法允许与Maven,Ant和其他构建工具的用户进行互操作.- sbt文档:跨构建发布约定
虽然这是一种简单的方法,但与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参考
将名称附加到名称是很久以前做出的历史决定,所以它很可能不会改变,因为许多库已经按照惯例发布.
话虽如此,正如Seth所说,几年前有一个讨论要回顾这个话题,当时sbt 0.12将"_2.10.0"后缀缩短为"_2.10",以利用Scala库在次要版本之间的二进制兼容性.这是来自[0.12]计划的马克:
通过交叉版本控制,我的意思是在模块ID中包含Scala版本的某些部分,以区分通过编译相同源代码生成的工件与不同的Scala版本.我并不是指使用多个Scala版本构建的能力
+task,这将保持不变; 我只是指交叉版本约定.[剪断]
以不灵活的pom.xml格式对其进行编码一直都是一种破解,我认为最好不要为Scala 2.10及更高版本构建的项目做好准备.但是,这可能比任何可能取而代之的临时解决方案更好.我没有看到其他构建工具的用户这样做,所以我希望没有什么可以取代它.
在Josh 建议的某个地方:
(1)Scala分类器.这些可以是自定义字符串,可以使用依赖项指定.至少,IIRC应该有效.
这是Mark的回应:
"可以用依赖关系指定"是什么意思？所有分类器只有一个pom,对吧？如何为每个分类器声明不同的依赖项？
以下是Geoff Reedy对分类器的一些更有趣的评论
我也认为分类器是处理这个问题的最佳方式,特别是考虑到maven docs中的分类器的建议,
java-1.4并且java-1.5用于在适合各自平台的罐子之间进行分离.致命的缺陷似乎是传递依赖管理.也就是说,没有办法根据用于要求模块的分类器选择传递依赖集.我们需要能够说,当你将这个模块与scala-2.10分类器一起使用时,它会使用分类器带来自己的依赖关系,scala-2.10并且当与2.9分类器一起使用时,它会使用分类器引入 自己的depsscala-2.9.我认为使用jvm版本可以使这项工作成为可能,因为jvm版本控制在配置文件激活中具有特殊支持,可以控制依赖项.