【发布时间】：2019-09-26 12:07:00
【问题描述】：
使用这种方案发布 Maven 项目是否是个好主意：
<groupId>com.oresoftware</groupId>
<artifactId>async.1</artifactId>
<groupId>com.oresoftware</groupId>
<artifactId>async.2</artifactId>
<groupId>com.oresoftware</groupId>
<artifactId>async.3</artifactId>
这些代表项目的主要版本在哪里？这不是创建不同命名空间的有效方法，以便树中的不同依赖项可能依赖于该库的不同版本吗？有没有人这样做或者这是一种不好的做法？
我什至也在考虑通过次要版本来命名它们：
<groupId>com.oresoftware</groupId>
<artifactId>async.1.1</artifactId>
<groupId>com.oresoftware</groupId>
<artifactId>async.1.2</artifactId>
<groupId>com.oresoftware</groupId>
<artifactId>async.1.3</artifactId>
更新，据说这是 Apache Commons 在版本 3 和 4 之间所做的，这里有两个不同的导入：
第 3 版：
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.2.2</version>
</dependency>
第 4 版：
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-collections4</artifactId>
<version>4.0</version>
</dependency>
所以我的问题是 - 要拥有不同的包名称或命名空间，使用不同的 artifactId 是否就足够了，还是我们还需要不同的 groupId ?
【问题讨论】：
-
对此的简单回答：否。使用完全符合预期的版本标签并使用语义版本控制...
-
我的理解是版本标签not实际上允许在一个应用程序中使用两个不同版本的“相同”依赖项？
-
这是不允许的，因为它没有意义，因为你不能在类路径上有重复的类，也不能像 Java 模块这样的东西不起作用。并且需要拥有同一工件的不同版本是一个真正的问题..还有一个问题：您为什么需要这样的东西？
-
不是我的代码需要不同的版本（尽管这种情况在极少数情况下会发生）——相反，我的一些依赖依赖于不同的版本。这叫做依赖地狱，是可以避免的，Java没有很好的避免。
-
"要拥有不同的包名或命名空间，使用不同的 artifactId 就足够了，还是我们还需要不同的 groupId？" 使用不同的就足够了工件 ID。更改一项或两项之间没有功能差异，它仅用于组织目的。请参阅Guide to naming conventions on groupId, artifactId, and version，这可能有助于您确定是否应该同时更改两者。