Maintaining patches of third-party Java library dependencies
My Java project has a dependency on a third-party library, let’s call it xyz.jar. My project is maintained in git and xyz in svn. xyz is included in my project as a Maven dependency so that it gets downloaded automatically as part of the build process.
I need to make minor tweaks to the source of xyz, but still want to get updates from the project maintainers. What options do I have?
- chromedriver fails on windows jenkins slave running in foreground
- How to inspect openshift build log?
- Version control for aggregatation of multiple projects using Maven / Git
- Jenkins, Maven, Nexus - Deploy 3rd Party JAR to Nexus Where Authentication is Needed
- Problems with merging after a git update-index --assume-unchanged
- My artifact seems to big to be deployed by maven. What can I do?
Currently, the best option seems to be to this:
- Fork the svn repo for xyz into a new git repo using
git svn clone.
- Hack on the git repo.
- Build xyz-hacked.jar from the git repo and export the artifact to a maven library server.
When new changes come out for xyz, I can do a
git svn rebase to keep my git repo up to date.
What are the best practices here? Can I improve on this approach?
I know there will be some manual work involved, e.g. resolving merge conflicts and ensuring my patches are compatible with the latest xyz. I’m not looking for a general, automated code merge solution. I’m trying to find out what the best practices and tools are in this situation.
I don’t think this is a Gradle-specific question, but just in case there’s a Gradle-specific answer: I’m using Gradle to include xyz.jar as a ‘compile’ dependency.
2 Solutions collect form web for “Maintaining patches of third-party Java library dependencies”
No matter what approach you use, it will always be labor-intensive.
Explicit conflicts will occur, but more insidious, any change anywhere in the base can totally break your local mods, even a change in a source file your local mods don’t touch (i.e. an interface signature you depend on).
Each and every rebase will require manual merging and complete regression testing on the 3rd party library AND your applciations that depend on the library.
By definition, this is not automatable.
I think you should consider the following points in respect to your approach:
- You don’t know how exacltyy project maintainters will change the source code. Therefore, while you will be able to apply most updates using rebase, at some point you will eventually face a conflict which you will have to resovle manually.
- This 3rd party library probably do not change very often. Even if it does, it doesn’t mean that you have to update your dependency immeidately. What for? There could be lots and lots of updates to that library which doesn’t affect your code anyhow. So why bothering with it?
My opinion is that such kind of problems should not be automated anyhow since this happens pretty rare and require your manual intervention anyway. I.e. you will spend much more time trying to automate this than in case you parform manual rebuilds, say, once in half-a-year.