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?

Currently, the best option seems to be to this:

  1. Fork the svn repo for xyz into a new git repo using git svn clone.
  2. Hack on the git repo.
  3. 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.

  • Best ways to deal with properties values in XML file in Spring, Maven and Eclipses
  • Can't find artifact bitcoinj:jar:0.11
  • Why can't my tests see my system property when I release on Jenkins?
  • Creating Maven assembly with files from different Git branches
  • Best way to run J-Meter test's from jenkins
  • Pass variable from jenkins to testng.xml
  • Weird URL-behaviour with Maven Release-Plugin
  • how to manage a forked git repo using maven
  • 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.

    Git Baby is a git and github fan, let's start git clone.