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

Question

由于Scala -versions 之间只有源兼容性,因此您不得不为它们支持的每个scala版本编译scalatest或scalamock等库.让我感到困惑的是,这些库提供了大量的工件(scalatest_2.9.0,scalatest_2.9.1,scalatest_2.10等等) - 每个scala版本都有一个,这样maven存储库中就堆满了许多由人工制作的文物.相同的来源.我的直觉告诉我宁愿为每个scala版本使用一个带有分类器的工件.(事实上​​,maven pom参考提到有时用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”或“ source-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构建生态系统中。