maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <>
Subject Re: Figuring out the proper Maven dependency setting
Date Thu, 11 Nov 2010 01:04:09 GMT
On 10/11/2010 4:37 PM, Brian Topping wrote:
> On Nov 10, 2010, at 4:20 PM, Ron Wheeler wrote:
>> It is mostly exclusions to stop old versions of libraries from being dragged in by
>> It took a bit of doing to get these the first time but it is nice now that we do
not have a screen full of conflicting version notes.
> So I guess you are then having to manually import the dependencies that you are excluding?
 That is seriously painful.
We only did that once about a year ago. It was painful but now life is 
commons-logging is specified once for 60 projects and I know exactly 
what version is used everywhere.

> It seems to follow that you would also want to set exclusions on all the excluded dependencies
that you manually import, right?  I mean, there's no telling that you might get a version
of a transitive dependency somewhere that has two versions!  :-)
No need that I can see for this.
> At that point, I don't know why you would bother with Maven at all.
Maven manages all this for us,  builds all the right libraries. Tiny 
little POM files that are easy to maintain. Few dependencies and no 
exclusions. Easy to make a new one. Just copy and old one and change a 
few fields on the first screen of the POM editor.
>   The effort required to disable all the dependency functionality (one dependency at
a time) is so much more painful than using it well.
Not painful at all. No overhead once we set up our dependency POMs.
> I'm not trying to be mean here, just trying to illustrate how the situation degenerates.

> Have you tried not using exclusions at all, then using dependency:tree to debug conflicts?
 Classpath conflicts where there are two versions of the same jar are usually pretty easy
to spot, and when they happen, they make such a big mess of everything that it's hard to miss.
 But dependency:tree will show you one or two root causes of the problem, then you can put
in a single exclusion on the precise jar that is causing the problem.  Problem solved, and
you still get updates to transitives like God intended.
Sure. That is how we started. Pain was constant. Drove us crazy. 
Conflicts all over the place. Multiple versions of third party libraries 
on the classpath. Never knew which combination was going to go in at 
Once you get 70 portlets, servlets and web services to watch, you want 
to know what version of third party libraries you are building with.
If we decide to go to the latest Apache-POI, we just change it one place.
We do it carefully after a discussion about impact and risk.  We verify 
what other dependencies will be affected. But we only do it once and we 
do it under control.

No conflicts. Only things that break, are stuff that we wrote.

Another small note. We put all our shared libraries at the Tomcat level. 
Our war files are small and generally consist exclusively of our own code.
We only load 1 copy of commons-logging onto the server.

The scores of libraries are all aggregated into 10 library jar files 
that go on /lib.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message