I found a minor bug in a bigger application framework that I am using. Fixing requires only to change two lines in a single class. I fixed the issue and pushed the changes to the project's repository.
However, I need to release tomorrow. Therefore, I cannot wait until the library is releasing a new version. I am wondering what would be the best way to integrate the patched version into my project:
Build the project: This I find quite difficult, I cannot even build it properly since so many unit tests are broken in the snapshot repository and even without the unit tests I do not get very far since I am obviously missing some dependencies that cannot be found in Maven Central. Also, I need to send the fixed version along to every other developer since it cannot be found on Maven Central. (We work on the net and we do not have our own Nexus.)
Adding a new module to my project where I keep a copy of the class that I have fixed. I then add this module as a dependency to all modules that should use the overriden version of the class. But how is the JVM determining which class it actually loads? It will find two jar-files that contain a class with the same name. Which one will it actually load? If I could make this work, this would allow me to integrate the modified version of the class with my project such that I could distribute the patch together with the project and once the bug gets fixed, I could simply remove the module.
I am including the modified class file into the affected module itself. So far, this appears as the easiest solution to me since the JVM will always load the class from the same jar first. (Am I right? At least that is what I observed in my tests.)
Thanks for any input on this.
I ended up building the project separately and moving this version to another namespace. This is apparently not so uncommon. For example Hibernate keeps cglib in its own namespace in order to avoid version conflicts due to API changes.
The first suggested solution had a problem when the project I used was also used in another dependency what led to that both my modified version and the normal version were on the class path what led to very strange behavior due to naming conflicts.
The second and third suggestion had similar problems as the first suggestion. Additionally, I broke compatibility to other versions of the dependency.
Even it sounds painful: Moving out of the namespace and providing a seperate build is a must, even if you only change a few lines of code.