AFAIK, provided is not transitive, so a provided dependency is assumed to be provided by any consumer of b
On Mon, Jul 28, 2008 at 10:48 AM, Mark Hobson <[EMAIL PROTECTED]> wrote: > Ping.. can anyone share some insight on this please? > > Mark > > 2008/7/22 Mark Hobson <[EMAIL PROTECTED]>: > > Hi there, > > > > I've encountered an issue with the scope resolution for nearest test > > and farthest provided scenario. Consider the following projects: > > > > a -> commons-lang > > b -> commons-lang > > c -> a:test, b:provided > > > > Where -> denotes a dependency and group ids, types and versions have > > been omitted for brevity. The dependency tree for c looks like this: > > > > c > > +- a:test > > | \- commons-lang:test > > \- b:provided > > \- (commons-lang:provided - omitted for duplicate) > > > > Thus the associated classpaths are: > > > > compile classpath: b > > test classpath: a, b, commons-lang > > > > This means that b loses its commons-lang dependency on the compile > > classpath. I'd have expected to see the following dependency tree: > > > > c > > +- a:test > > | \- (commons-lang:provided - scope updated from test; omitted > > for duplicate) > > \- b:provided > > \- commons-lang:provided > > > > With the associated classpaths: > > > > compile classpath: b, commons-lang > > test classpath: a, b, commons-lang > > > > This would entail changing the resolution for test/provided scopes to > > provided, see: > > > > > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Scoperesolution > > > > What do others think, am I missing something here? > > > > Cheers, > > > > Mark > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
