为什么scala maven工件对每个scala版本都有一个工件，而不是每个scala版本的一个分类器？

Question

由于您只有Scala-版本之间的源代码兼容性，因此您不幸需要为它们支持的每个scala版本编译类似scalatest或scalamock的库。让我感到困惑的是，这些库提供了大量的工件（scalatest_2.9.0，scalatest_2.9.1，scalatest_2.10等） - 每个scala版本都有一个工具，这样Maven仓库就会散布许多人工制品，这些工件由同一来源。我的直觉告诉我，每个scala版本都要使用一个分类器的工件。 （实际上，maven pom reference提到这有时是用jdk14和jdk15分类器来完成的，这与我看起来很相似。）那么，为什么Scala的人会为许多神器矫枉过正:-)呢？

Answer 1

我可能是错的，但如果一个分类的目的是为了“区分同一POM都建立了，但它们的内容不同神器”，然后我看到一个很好的理由不将它们用于scala版本控制：scala版本不仅仅是二进制不兼容，它们很可能是源不兼容。 举例来说，当将scala从2.7升级到2.8时，我不得不对代码库进行一些重大更改。如果我想同时保持scala 2.7和2.8版本，我将需要创建一个并行分支，并且两个分支绝对不会有相同的源代码。

当我读到“来自同一个POM”时，我明白它也意味着来自相同的源代码，这显然不是这两个代码分支的情况。

另一个更重要的原因是分类器基本上是一个单独的字符串，它已经用于很多事情。或多或少的标准分类器包括“来源”，“javadoc”或“资源”。这些分类器的含义在scala项目中是相同的，并且与scala版本完全正交，正如我试图展示的那样。

Maven的文档建议使用诸如“jdk15”或“jdk14”之类的分类符来表示二进制工件编译的jvm版本。 鉴于Java代码是向后兼容的，原则上两个分类器（“jdk15”或“jdk14”）的工件都是从相同的源代码编译而来的。这就是为什么你不需要为“源”神器复制分类器，换句话说你不需要有一个名为“sources-jdk14”和“sources-jdk15”的分类器。 但是你不能将相同的基本原理应用到scala版本：鉴于你可能需要不同的源代码，无论你是使用scala 2.7还是scala 2.8进行编译，你确实需要两个不同的工件，例如“sources-scala2.7”或“源极 - scala2.8”。所以我们已经有了复合分类器。 对于二进制工件，您不仅需要区分目标jvm版本（请记住，您可以编译您的scala代码以针对不同的jvm版本），还需要对它进行编译的scala版本进行区分。所以你最终会得到类似“jdk14-scala2.7”或“jdk14-scala2.8”或“jdk15-scala2.7”或“jdk15-scala2.8”的东西。又一组复合分类器。 所以带回家的消息是，scala版本实际上是对工件进行分类的独立方式，与所有现有的分类器完全是正交的。 是的，我们真的可以像上面那样使用复合分类器（比如“sources-scala2.7”），但是我们不会使用标准分类器，这本身就足够令人困惑，但也需要修改分类器周围的所有工具：如果我使用的构建工具不知道scala（仅限于java），但知道如何自动发布“源”工件？我是否需要修改此构建工具，以便他知道要发布“sources-scala2.7”工件？另一方面，如果我在（基本）工件名称中编码scala版本并将其提供给构建工具，则一切正常，我会用“源”分类器得到一个工件。

总而言之，与直觉相反，在名称中编码scala版本允许将更好地集成到现有的java构建生态系统中。

Answer 2

Scala仅在跨版本（Major.Minor.Patch版本规范的第三个组件）中提供了其字节码输出（.class文件）的版本间兼容性。

Maven没有地方可以正确地将它编码为工件的第一类属性，所以它必须按名称中的约定进行编码。

悲哀的