You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Mark Hobson <ma...@gmail.com> on 2008/07/22 17:14:51 UTC
Incomplete classpath due to scope resolution for test/provided
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Incomplete classpath due to scope resolution for test/provided
Posted by Mark Hobson <ma...@gmail.com>.
2008/7/28 Mark Hobson <ma...@gmail.com>:
> You're right that provided is not transitive, although this example
> relates to scope resolution which occurs when an artifacts has two
> different scopes. See:
>
> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Scoperesolution
Found this related issue if anyone's following:
http://jira.codehaus.org/browse/MNG-2686
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Incomplete classpath due to scope resolution for test/provided
Posted by Mark Hobson <ma...@gmail.com>.
2008/7/28 Stephen Connolly <st...@gmail.com>:
> AFAIK, provided is not transitive, so a provided dependency is assumed to be
> provided by any consumer of b
You're right that provided is not transitive, although this example
relates to scope resolution which occurs when an artifacts has two
different scopes. See:
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Scoperesolution
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Incomplete classpath due to scope resolution for test/provided
Posted by Stephen Connolly <st...@gmail.com>.
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 <ma...@gmail.com> wrote:
> Ping.. can anyone share some insight on this please?
>
> Mark
>
> 2008/7/22 Mark Hobson <ma...@gmail.com>:
> > 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Incomplete classpath due to scope resolution for test/provided
Posted by Mark Hobson <ma...@gmail.com>.
Ping.. can anyone share some insight on this please?
Mark
2008/7/22 Mark Hobson <ma...@gmail.com>:
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org