> Why? Only with dependencyManagement you're able to manage transitive > versions. In order to keep clean dependency graphs I have used standard OO principles to encasulate functionality in this case I will use spring as an example.
Spring provided many artifacts. I have many projects that use different groups of spring projects so I have pulled the spring dependencies out into two compositions one that deals with contexts and the other persistence. All my projects depend upon those compositions which means that all aggregations end up with bottleneck in the dependency graph at the point where the actual spring versions are resolved. Hence no conflict in the jars that actually end up in aggregations. On other key thing is a careful use of ranges to restrict which version of the composition is pulled in. For example at the moment i have one for spring [2.0,2.1) and one for [2.1,2.2) its impossible for an aggregation via two different trees to accidentally include spring 2.0.6 and 2.1-beta for example as the maven dependency will complain of an over contrained dependency. This evangenlism is usually accompanied by a A2 page of dependency graph scribbles ;-) > They are optional, so you do not depend on them transitively. > so in order to enable something thats optional i have to include those same dependencies myself? Rather than depend upon an artifact that will resolve only the dependencies I want and the correct graph for what I need? http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html "Optional dependencies are used when it's not really possible (for whatever reason) to split a project up into sub-modules. The idea is that some of the dependencies are only used for certain features in the project, and will not be needed if that feature isn't used. Ideally, such a feature would be split into a sub-module that depended on the core functionality project...this new subproject would have only non-optional dependencies, since you'd need them all if you decided to use the subproject's functionality." > Commons logging has a different philosophy. But this is OT for this list. If the difference in philosophy means more difficulty in managing dependency graphs then its not OT for this list but very pertinent. On Tuesday 28 August 2007 18:03, Jörg Schaible wrote: > Hi Michael, > > Michael McCallum wrote on Tuesday, August 28, 2007 12:34 AM: > > IMO the log4j, logkit, avalon dependencies all need to go... I as I > > imagine most people do only use one logging implementation in the > > deployed systems why introduce a dependency on several > > implementations at the top level? > > They are optional, so you do not depend on them transitively. > > > check out http://www.slf4j.com for an appropriate break up of the > > artifacts and use cases > > Commons logging has a different philosophy. But this is OT for this list. > > > I've generally stopped using dependencyManagement in favour of > > dependency composition > > Why? Only with dependencyManagement you're able to manage transitive > versions. > > - Jörg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Development Lead Ferrit Ltd cell: 021.576.907 msn: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] aim: gholamses http://www.ferrit.co.nz --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
