On 20/07/2010 5:53 AM, Ben Caradoc-Davies wrote:
On 20/07/10 14:50, Barrie Treloar wrote:
On Tue, Jul 20, 2010 at 2:09 PM, Ben Caradoc-Davies
<ben.caradoc-dav...@csiro.au> wrote:
The problem I am trying to solve is to automatically determine which
higher
level artifacts need to have their dependencies updated when a lower
level
artifact is updated. Extra credit for being as simple and
easy-to-use as
dependency:tree. :-)
Why do you want this?
Dont you want control over when to upgrade your dependencies?
Yes. I have large projects with deep dependency trees. If I change a
low-level artifact and want to apply this effect everywhere, I need to
know which artifacts to change (the ones that consume it directly or
indirectly). I want to display the dependency graph so I know which
artifacts to change.
One way to minimize some of the effects of low level changes is to build
projects that aggregate common dependencies.
We have done this with success for both internal and external libraries.
The application level jars do not depend on the low level artifacts.
Instead, they depend on an aggregation project that identifies a set of
lower level artifacts and builds an aggregated jar.
This way the application author does not have to worry about which
version of the lower level artifacts but just depends on the correct
version of the aggregated project.
It ensures that applications are built using a single version of an
artifact. Once the person planning the application decides that
application version y will require x version of commons-logging,
everyone gets it automatically by depending on the y version of the
our-apache project which will define that version x of commons-logging
is to be used.
It also makes the application levels POMs very small and very stable.
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
