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

Question

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

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

一个不错的解决方案是使用修补的库源创建一个独特的项目，并使用-patched限定符将其部署在本地/企业存储库中。但这不适合开源项目，任何检查其来源的人都可以轻松构建。或者我应该只说“并且，在构建我的项目之前，请检查那些东西并运行mvn install”。

Answer 1

  

一个不错的解决方案是使用修补的库源创建一个独特的项目，并使用-patched限定符将其部署在本地/企业存储库中。但这不适合开源项目，任何检查其来源的人都可以轻松构建。或者我应该只说“并且，在构建我的项目之前，请检查那些东西并运行mvn install”。

这是我为公司和开源项目做的事情（实际上我做的事情）。获取源代码，将它们置于不同项目的版本控制之下，对它们进行修补，重新构建修补的库（并在版本中包含此信息，如XYZ-patched），将其部署到存储库（您可以使用SVN， Google代码 ¹ ），在您的POM中声明存储库并更新依赖关系以指向修补版本。

使用这种方法，您可以对您的用户说：查看我的代码并运行mvn install，他们只会获得修补版本而无需任何额外操作。这是恕我直言最干净的方式（不容易出错，没有类路径命令混乱，没有增加构建时间等）。

¹ 很多人正在将他们的代码部署到他们托管的subversion存储库（this post中的方法）。

Answer 2

  

一个不错的解决方案是使用修补的库源创建一个独特的项目，并使用-patched限定符将其部署在本地/企业存储库中。但这不适合开源项目，任何检查其来源的人都可以轻松构建。或者我应该只说“并且，在构建我的项目之前，请检查那些东西并运行mvn install”。

我同意这一点和Pascal的回答。一些补充说明：

• 如果您不想重建整个依赖项目，可以在原始工件上使用dependency:unpack，然后将其与编译后的类组合使用
• 在任何一种情况下，您的pom.xml都需要正确表示该库的依赖关系
• 您仍然可以将其作为项目构建的一部分进行集成，以避免“部署到存储库”步骤
• 确保您在执行此操作时遵守项目许可证的约束！