I think the dependencyManagement mechanism is Less usefull,because when the transitive dependency conflict. In some case, It need strict function and pressure test to decide which version to use. and the SCM should control the authority to decide which version to override another depends on the test result. so the config should not be define in the pom.xml.
2008/10/8 Stephen Connolly <[EMAIL PROTECTED]> > OK, I'll start back a piece from your question. > > When you do > > <project> > ... > <artifactId>a</artifactId> > ... > <dependencies> > <dependency> > <groupId>foo</groupId> > <artifactId>bar</artifactId> > <version>1.0</version> > </dependency> > ... > </dependencies> > ... > </project> > > what you are doing is telling maven that your project a needs foo:bar > and would, if its opinion counts, prefer to use version 1.0 > > If I have another project with > > <project> > ... > <artifactId>b</artifactId> > ... > <dependencies> > <dependency> > <groupId>foo</groupId> > <artifactId>bar</artifactId> > <version>2.0</version> > </dependency> > ... > </dependencies> > ... > </project> > > If project c lists a & b as it's dependencies, which version of > foo:bar will maven use? > > a would prefer 1.0 > b would prefer 2.0 > > There are rules which allow Maven to deterministically figure this out > (in this case the first dependency listed in project c will win, > unless c depends on foo:bar directly itself) > > so for > > <project> > ... > <artifactId>c</artifactId> > ... > <dependencies> > <dependency> > ... > <artifactId>b</artifactId> > ... > </dependency> > <dependency> > ... > <artifactId>a</artifactId> > ... > </dependency> > ... > </dependencies> > ... > </project> > > c will end up using version 2.0. > > The dependencyManagement is a way of more strongly hinting to maven > that it should use a specific version... > > so since c does not directly depend on foo:bar, we don't really want > to add foo:bar as a dependency of project c. > > By adding it as a dependencyManagement we can tell maven, oh by the > way, if you see this dependency, i'd really really like it if you can > use this version. > > The other use case for dependencyManagement is to put it in a parent > pom... that way all the parent's children do not have to keep > specifying the version... in fact they can safely omit the version > > -Stephen > > 2008/10/8 Wayne Fay <[EMAIL PROTECTED]>: > > Primarily, <dependencyManagement> does not actually attach an artifact > > dependency to a given project, while declaring a <dependency> does > > exactly that. > > > > So you could have a project with 10 items in depMgmt and no deps which > > tells users (and Maven) that it can be built all on its own. > > > > Wayne > > > > 2008/10/8 陈思淼 <[EMAIL PROTECTED]>: > >> <dependencyManagement> > >> <dependencies> > >> <dependency> > >> <groupId>test</groupId> > >> <artifactId>d</artifactId> > >> <version>1.0</version> > >> </dependency> > >> </dependencies> > >> </dependencyManagement> > >> > >> > >> <dependency> > >> <groupId>maven-test</groupId> > >> <artifactId>c</artifactId> > >> <scope>runtime</scope> > >> </dependency> > >> </dependencies> > >> > > >
