It appears that the second solution will get you what you want and make
it much more explicit so that when/if you remove B, you will see the
dependency on L and just have to change its scope.
I am not too excited about extra libraries in production since they are
only loaded when required and most are small.
If it is a huge library, you would want to be more careful.
I am a little surprised that Maven would not include L in the production
artifact.
We manage dependencies very tightly and would have set up our POM as
suggested in 2 and not worried about the "test" scope since L is always
there (in your current case).
You might want to file a bug report and see what the developers say or
do about this.
There is not much that you can do in the user forum can do to resolve
this properly but you seem to have a workaround pretty well under control.
Ron
On 19/01/2012 9:37 AM, Mickael Marrache wrote:
On the contrary, I would need the dependency on L with compile scope.
The first solution you propose ( a) ) is what I use for now, but I don't
understand why Maven can't decide that here the final scope has to be compile
and not test. This solution seems to be temporary and by removing the
dependency, you lose trace in your POM that you also use L directly from
project A, and if in the future, you decide to remove the dependency of project
A on project B, you'll need to add the test-scoped dependency on L in the POM
of project A. This is the same for the second solution, if you remove the
dependency on B in the future, you'll get the L library in your classpath (even
for production).
Am I right or missing something here? Do you think it can be added as a "new
feature"?
Mickael
-----Original Message-----
From: Ron Wheeler [mailto:[email protected]]
Sent: Thursday, January 19, 2012 4:28 PM
To: Maven Users List
Subject: Re: Dependency scope precedence?
Not sure why you would need the dependency on L with test scope.
It appears that project A always has project B which always needs L.
L has to be there regardless of whether you are in test or production.
It appears that you could just
a)remove the reference from A to L or
b) make it compile if you want and exclude it from A's dependency on B
if you want to control the version in project A
Am I misreading your description?
Ron
On 19/01/2012 5:37 AM, Mickael Marrache wrote:
Hi,
I have a project A that uses library L v1.0.0 with test scope.
Project A also depends on project B (with scope compile), with B transitively depending on the library L
v1.0.0 (with scope compile). So, according to the documentation (Introduction to dependency mechanism),
project A depends on project B with scope "compile" and the transitive dependency on L has a
"compile" scope, the final scope of L should be "compile".
Here, Maven sees one dependency on L with scope "compile" (after applying the dependency
algorithm), and one dependency on L with scope "test". Why the final scope of the library
L for project A is 'test'? It seems that the dependency definition of project A on library L
overrides those of the transitive dependencies on L.
It causes me NotClassDefFoundError at runtime.
What's wrong here? My project A only uses L for unit tests so I define the
dependency with 'test' scope. But, at the end, I want L to be on my classpath
since project A depends on project B for production, and B needs (transitively)
library L also for production. (By production, I mean not unit tests.)
Thanks for helping me
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
