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

Question

假设,我有一个依赖于某个库的开源项目,必须修补它才能解决一些问题.我怎么做？我的想法是:

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

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

Answer 1

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

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

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

¹很多人正在将他们的代码部署到他们托管的subversion存储库(本文中的操作方法).