Java 类路径中的版本控制信息

我正在创建一个API库，该库将部署到客户的内部部署应用程序中。此内部部署应用程序包含独立的插件模块，这些模块包含作为依赖项的API库。每个应用程序可能有几个插件，因此API库有很多副本

我希望能够灵活地改进API库，同时避免类加载器冲突。OSGI实现目前不是一个选项。我想知道是否有人在类路径中放置版本控制信息，以创建不同的类实例化，从而避免冲突

e、 g

com.product.v2014_04包中的User.java（第1版）

com.product.v2014_05包中的User.java（第二版）

有没有人有这样做的经验，或者知道有什么流行的实现使用这种方法来避免类路径冲突？赞成/反对

---

非常感谢

Apache通过他们的一些库实现了这一点。如果您查看commons lang（）的旧版本，那么所有包都位于

org.apache.commons.lang

中。不过，去获取它的当前版本（），您会注意到所有包都已重命名为

org.apache.commons.lang3

---

当我最近将一个应用程序从2.6迁移到3.3时，检查并修复我所有的导入语句有点痛苦，但它确实说明了这是一个重大的版本更改，我需要注意如何使用代码。

这不是标准API版本控制的好方法。。。使用该API的每个客户机都需要随每个版本进行更改。我建议在类路径上只使用最新版本，并且只进行向后兼容的更改。如果您需要打破向后兼容性，那么这可能是引入新包名的时候了。谢谢您的回复。如果API库总是作为依赖项（例如fat jar）与每个插件一起打包，会怎么样？我知道这会导致代码重复，但在这种情况下它有效吗？我认为如果代码重复不是源代码重复，那么代码重复就不是什么问题。如果它只是一个包装“东西”，那么它就可以了。只要确保您不需要在插件之间共享实例。。。你知道，

Foo.class！=类

问题。此外，一些主要框架将其核心依赖项捆绑在自己的包中，以防止与用户库发生冲突。例如，Spring框架在其自己的包中重新打包CGLIB。但这只能应用于真正的内部非共享依赖项（甚至不能与库中的其他依赖项共享）。我不记得以前在哪里见过这个，但后来我想到了：org.springframework.orm.hibernate3。因此，将主版本号放在包名称的末尾似乎是一种常见的方法。