This one is a bit of a post for the techies, so if you’re more interested in the business side of my blog you may want to skip this post.
One of the things that, on paper, Apache 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. One example is Freemarker which 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…..