Forum Controls
Spotlight Features

The Rich Engineering Heritage Behind Dependency Injection

Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.

NetBeans 6: Matisse Updates

NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed.

Introduction to Groovy Part 3

In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.

Easier Custom Components with Swing Fuse

Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.

Benchmark Analysis: Guice vs Spring

Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Replies: 0 - Pages: 1  
Threads: [ Previous | Next ]
  Click to reply to this thread Reply

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

URL: Maven Repository

At 4:02 AM on Jan 24, 2008, Al Sutton wrote:

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. 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.....

thread.rss_message