but i want it managed across 75 artifacts in 11 groups with 9 aggregations... using inheritance to manage a change in the version of spring for example is way too time consuming and prone to error. Unless i specify all the deps in the aggregation i can never be sure of what version of any library i actually end up with
it might make more sense if you saw how i have the structure set up... the most important part of the development environment for me is that i can check out any maven artifact in isolation and work on it and release it... On Wednesday 29 August 2007 02:06, Jörg Schaible wrote: > Michael McCallum wrote on Tuesday, August 28, 2007 2:39 PM: > >> OK. But this will not help you, if you include another artifact that > >> depends transitively on Spring or Hibernate in different versions. > >> And therefore we use a company or at least a master POM for a > >> project with a dependencyManagement section. This way you can > >> overwrite the versions of the transitive deps. > > > > incorrect. maven will resolve the dependencies from closest > > to furtherest but > > not tranverse transitions if there is a better match. So if I > > hide all of the > > transitions behind a composition in all cases > > That's the point. By using the compositions you have to update them or > create new ones everytime you add a new dep. I simply add it to my > dependencyManagement. > > > - which means i > > have to exclude > > deps from 3rd party libraries in some cases - then the spring > > libraries are only resolved as transitions of composition and nothing > > else... as you can > > have on one instance of an artifact in the graph that gets > > selected there is > > on one set of transitions from the selected compositions... and voila > > consistent dependencies > > Since the depMgmnt oiverwrites the version of the inherited deps: voila no > inconsistent dep ;-) > > But you have your point. By using compositions you can combine them > individually, while the depMgmnt approach is kind of "all or nothing" for a > project. > > - Jörg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
