maven项目的布局，具有修补的依赖关系

Question

假设我有一个依赖于某个库的开源项目，必须对其进行修补以修复一些问题。我怎么做？我的想法是：

1. 将该库源设置为模块，将它们保存在我的vcs中。优点：简单。缺点：我的回购中有些第三方来源可能会减慢构建过程，很难找到修补位置（虽然可以在自述文件中修复）
2. 有一个模块，就像1一样，但只保留修补过的源文件，编译它们在类路径中使用orignal库jar，并以某种方式替换build中的库jar中的* .class文件。优点：构建速度更快，易于查找修补位置。缺点：很难配置，那个jar hackery是不明显的（库中的库jar和我的项目组件中会有所不同）
3. 在主/资源中保存修补* .class文件，并在包装​​中替换，如2）。优点：几乎没有。缺点：vcs中的二进制文件很难重新编译修补类，因为修补程序编译不是自动的。

一个不错的解决方案是创建一个独立的项目与补丁库源，并部署在具有-patched限定符的本地/企业存储库。但是这并不适合开源项目，任何人都可以轻松构建出源代码。或者我应该说“还有，在你构建我的项目之前，请检查一下这些东西并运行mvn install”。

Answer 1

一个不错的解决方案是创建一个独立的项目与补丁库源，并将其部署在具有-patched限定符的本地/企业存储库。但是这并不适合开源项目，任何人都可以轻松构建出源代码。或者我应该说“还有，在你构建我的项目之前，请检查一下这些东西并运行mvn install”。

这是我为企业和开源项目所做的（实际上是我所做的）。获取源代码，将它们置于独立项目的版本控制之下，修补它们，重新构建修补过的库（并在版本中包含此信息，如XYZ修补程序），将其部署到存储库（您可以使用SVN进行此操作， Google Code ），在POM中声明存储库并更新依赖项以指向修补的版本。

通过这种方法，您可以对用户说：检查我的代码并运行mvn install，他们只会得到修补版本而不需要任何额外的操作。这是恕我直言的最清洁的方式（不容易出错，没有类路径顺序混乱，不增加编译时间等）。

很多人正在将他们的代码部署到他们的托管Subversion版本库（如何在this post）。

Answer 2

一个不错的解决方案是创建一个独立的项目与补丁库源，并将其部署在具有-patched限定符的本地/企业存储库。但是这并不适合开源项目，任何人都可以轻松构建出源代码。或者我应该说“还有，在你构建我的项目之前，请检查一下这些东西并运行mvn install”。

我同意这和帕斯卡的答案。一些补充说明：

• 你可以在原来的神器使用dependency:unpack，然后结合起来，与您编译的类，如果你不想重建整个依赖项目
• 在这两种情况下，你的pom.xml需要正确地表示该库的
• 你仍然可以整合这是你的项目构建的一部分，以避免依赖关系“部署到仓库”一步
• 确保你的荣誉项目许可证的做这一切时的约束！