由于您只有 Scala 之间的源兼容性- 不幸的是你需要编译像 scalatest 这样的库的版本或 scalamock对于他们支持的每个 Scala 版本。令我感到困惑的是，这些库提供了大量 Artifact (scalatest_2.9.0、scalatest_2.9.1、scalatest_2.10 等)——每个 scala 版本都有一个，因此 maven 存储库中散布着许多从构建的 Artifact 同一个来源。我的直觉告诉我，宁愿为每个 Scala 版本使用一个带有分类器的 Artifact 。 (事实上，maven pom reference 提到这有时是用 jdk14 和 jdk15 分类器来完成的，这似乎与我很相似。)那么，为什么 Scala 人会去追求许多人工制品的矫枉过正:-) 呢？
最佳答案
我可能错了，但如果分类器的目的是“区分由相同 POM 构建但内容不同的 Artifact ”，那么我看到了一个很好的理由 不是 将它们用于 scala 版本控制:scala 版本不仅仅是二进制不兼容，它们很可能是 源不兼容 .
例如，当将 scala 从 2.7 升级到 2.8 时，我不得不对代码库进行一些重大更改。如果我想同时保留 Scala 2.7 和 2.8 版本，我将需要创建一个并行分支，并且两个分支肯定不会具有相同的源代码。
当我读到“来自同一个 POM”时，我明白这也意味着来自同一个源代码，这两个代码分支显然不是这种情况。
另一个更重要的原因是分类器本质上是一个单一的字符串，它已经被用于很多事情。或多或少的标准分类器包括“sources”、“javadoc”或“resources”。这些分类器的含义在 scala 项目中是相同的，并且与 scala 版本完全正交，我将尝试展示。
Maven 的文档建议使用诸如“jdk15”或“jdk14”之类的分类器来表示二进制 Artifact 是针对哪个 jvm 版本编译的。
鉴于 java 代码向后兼容，原则上具有两个分类器(“jdk15”或“jdk14”)的 Artifact 是从相同的源代码编译的。这就是为什么你不需要为“源” Artifact 复制分类器，或者换句话说你不要需要有一个名为“sources-jdk14”和“sources-jdk15”的分类器。
但是您不能将相同的基本原理应用于 scala 版本:考虑到您可能需要不同的源代码，无论您是针对 scala 2.7 还是 scala 2.8 进行编译，您确实需要两个不同的具有分类器的 Artifact ，例如“sources-scala2.7”或“源-scala2.8"。所以我们已经有了复合分类器。
至于二进制 Artifact ，您不仅需要区分目标 jvm 版本(请记住，您可以编译 scala 代码以针对不同的 jvm 版本)，还需要区分编译它所针对的 scala 版本。所以你最终会得到类似“jdk14-scala2.7”或“jdk14-scala2.8”或“jdk15-scala2.7”或“jdk15-scala2.8”之类的东西。又一组复合分类器。
所以带回家的信息是，scala 版本确实是一种对 Artifact 进行分类的单独方式，它与所有现有的分类器完全正交。
是的，我们真的可以像上面那样使用复合分类器(例如“sources-scala2.7”)，但是我们不会使用标准分类器，这本身就足够令人困惑，但还需要修改围绕分类器的所有工具:如果我使用一个不了解 scala(只有 java)但知道如何自动发布“源” Artifact 的构建工具怎么办？我是否需要修改这个构建工具，以便他知道发布一个“sources-scala2.7” Artifact ？另一方面，如果我在(基本) Artifact 名称中对 scala 版本进行编码并将其提供给构建工具，则一切正常，并且我得到一个带有“源”分类器的 Artifact 。
总而言之，与直接直觉相反，在名称中编码 Scala 版本允许 更好 集成到现有的 Java 构建生态系统中。
关于scala - 为什么 Scala Maven Artifact 为每个 Scala 版本都有一个 Artifact ，而不是每个 Scala 版本都有一个分类器？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15097600/