具有修补依赖项的 Maven 项目的布局
假设，我有一个依赖于某个库的开源项目，必须对其进行修补才能解决某些问题。我该怎么做？我的想法是：
- 将库源设置为模块，将它们保存在我的 vcs 中。优点：简单。缺点：我的存储库中的一些第三方源可能会减慢构建过程，很难找到修补的地方（尽管可以在自述文件中修复）
- 有一个模块，如1中，但仅保留修补的源文件，使用原始库编译它们jar 放在类路径中，并以某种方式在构建时替换库 jar 中的 *.class 文件。优点：构建速度更快，易于找到修补的地方。缺点：很难配置，该 jar 黑客攻击并不明显（存储库中的库 jar 和我的项目程序集中的库 jar 会有所不同）
- 将修补的 *.class 文件保留在 main/resources 中，并像 2 中那样替换包装。优点：几乎没有。缺点：VCS 中的二进制文件，很难重新编译修补过的类，因为修补程序编译不是自动化的。
一个不错的解决方案是使用修补的库源创建一个不同的项目，并使用 -patched 限定符将其部署在本地/企业存储库上。但这不适合开源项目，该项目旨在让任何检查其源代码的人都可以轻松构建。或者我应该说“而且，在构建我的项目之前，请检查这些内容并运行 mvn install”。
Suppose, I have an opensource project that depends on some library, that must be patched in order to fix some issues. How do I do that? My ideas are:
- Have that library sources set up as a module, keep them in my vcs. Pros: simple. Cons: some third party sources in my repo, might slow down build process, hard to find a patched place (though can be fixed in README)
- Have a module, like in 1, but keep patched source files only, compile them with orignal library jar in classpath and somehow replace *.class files in library jar on build. Pros: builds faster, easy to find patched places. Cons: hard to configure, that jar hackery is non-obvious (library jar in repository and in my project assembly would be different)
- Keep patched *.class files in main/resources, and replace on packaging like in 2). Pros: almost none. Cons: binaries in vcs, hard to recompile a patched class as patch compilation is not automated.
One nice solution is to create a distinct project with patched library sources, and deploy it on local/enterprise repository with -patched qualifier. But that would not fit for an opensourced project that is meant to be easily buildable by anyone who checks out its sources. Or should I just say "and also, before you build my project, please check out that stuff and run mvn install".
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这就是我为企业和开源项目所做的（实际上也是我所做的）。获取源代码，将它们置于不同项目中的版本控制之下，修补它们，重建修补后的库（并将此信息包含在版本中，例如 XYZ 修补程序），将其部署到存储库（您可以使用 SVN， a la Google Code1），在 POM 中声明存储库并更新依赖项以指向已修补的版本。
通过这种方法，您可以对您的用户说：查看我的代码并运行
mvn install，他们将获得修补版本，无需任何额外操作。恕我直言，这是最干净的方法（不容易出错，没有类路径顺序混乱，不会增加构建时间等）。1 许多人正在将代码部署到托管的 Subversion 存储库（
This is what I would do (and actually what I do) for both a corporate and an opensource project. Get the sources, put them under version control in a distinct project, patch them, rebuild the patched library (and include this information in the version, something like X.Y.Z-patched), deploy it to a repository (you could use SVN for this, a la Google Code1), declare the repository in your POM and update the dependency to point on your patched version.
With this approach, you can say to your users: check out my code and run
mvn installand they will just get the patched version without any extra action. This is IMHO the cleanest way (not error prone, no class path order mess, no increase of the build time, etc).1 Lots of people are deploying their code to their hosted subversion repository (how-to in this post).
我同意这一点和帕斯卡的回答。一些额外的注意事项：
dependency:unpack，然后将其与编译的类结合起来，您的pom .xml将需要正确表示该库的依赖项，I'd agree with this and Pascal's answer. Some additional notes:
dependency:unpackon the original artifact and then combine that with your compiled classes if you don't want to rebuild the whole dependant projectpom.xmlwill need to correctly represent the dependencies of that library