http://en.wikipedia.org/wiki/Relation_composition
group.id.composition.spring 2.0.6 -> spring-beans 2.0.6 -> spring-context 2.0.6 group.id.composition.spring.persistence 2.0.6 ->group.id.composition.spring 2.0.6 -> hibernate 3.1.3 -> spring-hibernate3 group.id.artifact.a X -> group.id.composition.spring.persistence [2.0, 2.1) group.id.artifact.b Y -> group.id.composition.spring [2.0, 2.1) group.id.aggregation Z -> group.id.artifact.b Y -> group.id.artifact.a X when building aggregation - think war or ear - you get a graph with a common composition element when it resolves you only get one of those and the resultant transitions down the graph I will concede the logging artifacts as OT but you may see me on commons later ;-) On Tuesday 28 August 2007 23:28, Jörg Schaible wrote: > Michael McCallum wrote on Tuesday, August 28, 2007 1:15 PM: > >> 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. > > [snip] > > You still did not explain, what "composition" means. It's no word used in > standard Maven terminology. Your description does not make it clear what > you *actually* have done. > > [snip] > > >> 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. > > It is OT, since it is up to the Apache Commons community how they carve > their artifacts. And splitting an artifact into 6 where 5 of them contain a > single wrapper class is where philosophy starts. You may discuss this at > Apache Commons. > > - 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]
