maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCallum <>
Subject Re: What is your strategy to manage dependencies?
Date Thu, 30 Sep 2010 01:15:58 GMT
> I'm not saying version ranges can't be a useful way of working, I'd just
> prefer to be sure of what was being delivered.

mvn dependency:resolve gives you a list of the dependencies... before I release any war projects
as release manager I check that it makes sense...

At the same time I want to be agile and make it as easy as possible to build the latest and
greatest, so two serial builds of the same project might pull in newer code. I can always
change the constraints to use an older version if tests/testing shows problems.

Ultimately i think whats delivered is a process issue and people are trying to use the tool
to do it and not very well. Ranges are really needed to define the constraints of any artifact
it terms of what the developer feels confident is compatible and the tool should barf when
those constraints are violated, and that is using a tool where it makes sense to validate.

As a release manager I trust my team to do a good job, they are testing and integration testing
and i'm happy to role up the latest and greatest and expect it to work (or at least be better
than the last one). I would expect they can provide enough defined rules to ensure if something
is wrong my build will break. aka range resolution conflicts. If I just run versions:update
I might get a conflicted resolution tree and no indication that its broken until i run it.

p.s. generated release poms have always caused major issues and it does actually make sense
to flatten a tree and expect the same results and resolving the tree. I do however record
the result of dependency:resolve in every jar that gets released so i can see what was used
to build it if i care to check later.


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

View raw message