Modifying files from external library in Java

Question

I have a Spring Framework project which uses Maven for resolving dependencies. The project has a dependency to another Spring project (Spring Social Facebook), which is used for Facebook login. Suddenly, I started to get a lot of errors because the Facebook login functionality broke due to changes in the Facebook API. The solution is extremely simple but requires a minor change within the external library's files - changing a variable from the type integer to long.

Now I know the solution, but I don't have control over this library. I would like to fix this problem myself until the library is updated with the fix, rather than waiting around for days with a broken system.

My question is: is there any easy way in which I can make a change to the source code of this library until a fix is available in the library itself? What is the recommended way of doing this? Two things currently come to mind: forking the library, make the change, and create a private Maven repository and replace the dependency with one that uses the private repository. If I can, I'd like to avoid that. The other way I can think of, would be to fork the library, make the change, compile the updated library into a jar file and replace the Maven dependency to use the jar file.

Is there a better way? What would you recommend in a (temporary) scenario like this? Thanks!

Answer 1

From working experience, in more than one company I have seen the following approach:

• Fix the issue in the source code
• Package it again with the same Maven coordinates
• Add a classifier, which was usually companyname-patch(ed)
• Put it in the enterprise Maven repository (i.e. Artifactory or Nexus)

As such, you would move from

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>4.7</version>
</dependency>

To

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>4.7</version>
  <classifier>company-patch</classifier>
</dependency>

This would help you to keep more traceability:

• The classifier makes it clear to internal developers and also to contractors that this is a company patch
• You know exactly to which library and which version the patch was applied (hence, partially self-documenting)

Furthermore, it is actually a legal and good usage of the Maven classifier feature.

Reusing the same Maven coordinates may affect portability (I have a different behavior on my local machine, why?) and maintainability (let's update this library, ops.. it was the patched one, I didn't know), while creating new Maven coordinates may create misunderstanding (what's this library?) and errors (I will replace by this official one, ops.. It doesn't work anymore).