Al has posted 3 posts at DZone. You can read more from them at their website. View Full User Profile

Is the maven repository creaking at the seams and starting to blow?

  • submit to reddit

One of the things that, on paper, maven appears to do well is dependency handling. It checks down the dependency chain to verify that libraries versions match up, and that the latest library is used..... except with the current repository it isn't guaranteed to work, and you can easily end up with multiple versions of the same jar on your classpath and not know about it.

The problem is with groupIds. In an ideal world there would be a one to one mapping between a groupId and a library, so, for example, everyone would refer to the freemarker library using the groupId org.freemarker, and all would be good.

Unfortunately this hasn't happened, and Freemarker is an example of what goes wrong. The Freemarker library can be referred to with either the groupId of "freemarker" or "org.freemarker", and if one of your dependencies uses the groupId freemarker and another uses the groupId org.freemarker you'll end up with two versions of the same library on your classpath (for freemarker at the moment it will most likely be 2.3.4 and 2.3.11).

I raised the freemarker issue as a JIRA issue for Maven (See MEV-570) to see if something could be done via some kind of redirect or an alias from one groupId to the other to ensure consistency. The response I received was;

"you need to use exclusions in your pom if you see that behavior
the repository is provided by the project and if they decide to move to a new groupId is something between you and them and their upgrade instructions for new versions"

Now as it happens the duplicate freemarker groupId issue has already been raised and the freemarker guys agreed to a relocation to org.freemarker (see MAVENUPLOAD-1419), but it was the maven guys who refused to do it, so even if you get the library owners to agree to the relocation, it still may not happen.

So currently if you use the main maven repository and you believe it's handling all your dependencies in a sane way, then you may want to think again, because if there's more than one groupId for a particular library it's your problem to find it, work around it, and even if the project owners want to fix the problem it just may not happen.

So is it just me that thinks that it's crazy to put the burden of checking onto every project developer when there is a central solution which would fix the problem?, Should the maven guys nominate someone to start a cleanup?, or is everything just lovely right now?, lets start the discussion.....

Published at DZone with permission of its author, Al Sutton. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Steven Devijver replied on Fri, 2008/01/25 - 9:37am

One of the bigger issues in Maven's design is that plugins are not released with the build system.

Automatically updating plugins is non-sense. For example, just yesterday the Emma plugin was updated, out of the blue. We had to upgrade to Maven 2.0.8 on all our developer machines and CI machines.

Maven is supposed to be about gaining time and not developing the build system, remember?

Jim Bethancourt replied on Fri, 2008/01/25 - 10:26am

Besides cleanup, it would be helpful to have a recommended, or even standardized, groupId and artifactId convention to avoid this situation in the future. Perhaps putting together a short Maven 2 Best Practices for Artifact Contributors would be helpful.

Jim Bethancourt

President, Houston Java Users Group

Technical Architect, ROME Corporation

Eugene Kuleshov replied on Fri, 2008/01/25 - 4:23pm

Naturally, if you didn't specify exact version of plugin you are using in your pom.xml Maven will look for updates and will alsways use the latest version. That is why it is a good idea to always specify plugin versions and I would call it one of the most critical maven best practices.

Luca Botti replied on Sat, 2008/01/26 - 3:45am

Of course, repository duplication is an issue - but remember, maven tries to guarantee repeateble build, eg, if I point to  freemarker groupId for my 1.0.1 pom, I should be capable of building it FOREVER. 

There is a mechanism inside the poms, which should be capable of pointing a newly released version to a different groupID, without cluttering the repository. But it's up to the projects owners to use it.

 groupIds and artifactIds, although far from perfect, are used in the dependency lookup mechanism, and the correctness of the repository relies on the deployers. Try to include commons-logging -  you will end up with a completely useless avalon-something in your application. This is not maven (or repository) fault, but is due to poor pom writing.



Steven Devijver replied on Sat, 2008/01/26 - 6:23am in response to: Eugene Kuleshov

Naturally, if you didn't specify exact version of plugin you are using in your pom.xml Maven will look for updates and will alsways use the latest version. That is why it is a good idea to always specify plugin versions and I would call it one of the most critical maven best practices.

That would indeed work if it were not that the old version is called 1.0-SNAPSHOT and the new version is called .... 1.0-SNAPSHOT.

Please, just release plugins together with the build system. Why be so persistent in doing the wrong thing?

Ophir Radnitz replied on Wed, 2008/01/30 - 3:29pm

Do you use a proxy as your remote repository?

the public repositories do suck ass but using a locally deployed proxy can really alleviate your problems. You still have to find the right artifacts, but you do it once. You can deploy those 3rd party artifacts in whatever scheme that makes sense to you and you're no longer dependant on online availability. For a development team this is a real productivity boost.

We use Artifactory. It's open source, lets you manage your deployed artifacts (both your own and 3rd-party ones) intelligently and has a sleak web UI.


Ophir Radnitz



firstname lastname replied on Sat, 2008/02/02 - 1:20pm

Even if you do create relocation poms for your consumers, they still might have issues if they use dependencyManagement. 

I posted this bug last week:

I hope more people vote for it, my team really needs this fixed.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.