Why you should use Old GroupIds Alerter – Maven Plugin

Your Java (or any JVM language) projects may depend on some third-party libraries. You know how to check for updates, but what happens when a third-party library gets no updates?

You didn’t notice that the FooLib library hadn’t been updated in over two years, and no one on your team cares.

What happened?

• Scenario 1: Foolib is a super stable library with no security breach. There is no reason to publish a new version.
• Scenario 2: FooLib is dead, and there is no drop-in replacement.
• Scenario 3: FooLib is dead, but there are some active forks.
• Scenario 4: FooLib has changed its Maven coordinates.
• Scenario 5: FooLib is dead, and there is no fork.

We won’t discuss scenario 1, everything is fine and we live in an ideal world 😁.

What should you do?

Scenario 2

FooLib is dead, and there is no drop-in replacement.

Take time to find an alternative and adapt your code. Or, it may be time to invest more time in your code and reduce your dependencies.

Scenario 3

FooLib is dead, but there are some active forks.

Check the reputation of the new maintainers (😉), replace these Maven coordinates, and ensure everything works as expected.

Scenario 4

FooLib has changed its Maven coordinates.

It happens all the time. Some examples:

• org.osgi:core moved to org.osgi:org.osgi.core
• velocity moved to org.apache.velocity
• com.fasterxml.jackson moved to tools.jackson (did you miss the Jackson Release 3 announcement?)
• org.hibernate:hibernate-core moved to org.hibernate.orm:hibernate-core
• com.microsoft.azure:azure-storage moved to com.azure:azure-storage
• io.reactivex.rxjava2 moved to io.reactivex.rxjava3 (I hate when a project does that. Why not create legacy coordinates?)
• etc.

You may need to rework some code, but it’s documented most of the time.

Scenario 5

FooLib is dead, and there is no fork.

Good luck.

How to prevent these issues?

Wait, Maven has a property for that: relocation! When a project coordinates change, the maintainer of the library has to publish a first release with the old coordinates, just to say you should use the new coordinates, then he can publish a second release with the new coordinates.

There are two problems:

• When a library dies and, later, is forked, the old maintainers don’t take time to publish a release just for that. It’s totally understandable and I can’t blame maintainers. They may not have time for that. Unfortunately, they could also be sick or dead. Finally, they may not want to take the responsibility to promote a fork.
• Even when a project is still active, its maintainers could think it’s a good idea to change some coordinates, they document it, they blog about it, but they forget to publish a release to inform us about the new coordinates. Developers who don’t read the blogs/documentation/changelogs of all their dependencies may miss these important changes.

So, the fact is the relocation attribute is not commonly used in real life.

Actually, there is a third problem: when a library just dies and nobody cares, it’s important to be informed about that. The relocation property can do nothing for that.

This is why I created a tool to address these issues: Old GroupIds Alerter. This is a Maven plugin, but I also created a Gradle plugin. There is no magic here: this is a community effort to maintain a list of relocations, and some dead libraries. It currently lists ~600 official relocations.

The Maven coordinates are:

<plugin>
    <groupId>biz.lermitage.oga</groupId>
    <artifactId>oga-maven-plugin</artifactId>
    <version>1.9.4</version>
</plugin>

It’s fully configurable: you can ignore some relocations, you can fail the build if the plugin says some of your dependencies have new coordinates, etc. It works with Maven dependencies and Maven plugins. For Gradle, it works only with dependencies.

To run the inspection, use the biz.lermitage.oga:oga-maven-plugin:check goal:

If you’re curious, the lists of relocations are here: https://github.com/jonathanlermitage/oga-maven-plugin/tree/master/uc. I started this project by loading the Maven Central indexes in order to find possible relocations (see this sub-project). They have all been verified. Now, new relocations are added manually, mostly when a project communicates about new coordinates (and, again, they mostly forget to use the relocation property). I also added some special relocations to removed:removed, which means there are no new direct coordinates. For now, this is only about Jetty migration from v11 to v12. Finally, some relocations are documented with links to the official documentations.

The Maven plugin is maintained and stable, even if I can’t spend too much time on it. The Gradle plugin is not actively maintained (I have no time for it – help is definitively needed) but it still works, and it uses the same list of relocations.

It is not the only tool that addresses this issue, but Old GroupIds Alerter is one of them. It is completely open source and free (MIT).

Finally, I would like to thank Filipe Roque for his regular and amazing contributions! 🙏