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 mistake.
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
grand.
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
run-time.
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.
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
