Your argument Jorg I think applies to provided and runtime scope, but not to test.
The root smell here lies in the definition of "scope". Test scope means needed to compile test code. Compile scope means needed to compile production and test code. These are both related to when a dependency is needed to compile. Provided and runtime scope are related to when a dependency is needed at runtime. So the way I see it, a compile transitive dependency should always override a test dependency but not provided or runtime. There is some technical debt here in terms of how scoping works. You really need a further scope classification like: Scope = compile classifier = test classifier = production Scope = runtime classifier = provided Something like this. You likely get the idea. --- Todd Thiessen > -----Original Message----- > From: news [mailto:[email protected]] On Behalf Of Jörg Schaible > Sent: Friday, May 08, 2009 9:11 AM > To: [email protected] > Subject: Re: Transitive and inherited dependencies - > potential bug, or my misunderstanding of the mechanism > > Hi Stevo, > > Stevo Slavić wrote at Freitag, 8. Mai 2009 14:15: > > > Issue is elsewhere. Initial example I gave included > inheritance, but > > unwanted behavior happens even without it. > > > > E.g. if project P has test scoped dependency to a LIB1, and compile > > scoped dependency to LIB2, while LIB2 has compile scope > dependency to > > LIB1, currently project P's war will wrongly end up without > LIB1 included. > > This is the whole point: This is not wrong, Maven did it > right! Actually we use scope narrowing to trim down > dependencies that are not needed/only needed for test or > provided by the container. > > > In P > > one expects LIB1 to be available for testing, but that shouldn't > > affect availability of LIB1 as compile scoped transitive > dependency, > > it should be the other way round, in this case scope of > declared test > > scoped dependency should be broadened. > > Although Maven helps you with Dependency management, it is > still your task as dev to actively maintain them. This > implies a check of the dependency tree. > > > As I wrote earlier, things are made worse by fact that > during regular > > packaging/install of such an artifact no warning message is printed > > about narrower scope being chosen, so without appropriate > (functional) > > tests or checking of dependency:tree one ends up knowing that > > dependency is missing only at runtime (it's a thril when it > happens very late, at production... > > :) ). > > Broadening the scope will have some really nasty other > side-effects which will again put you in the role of actively > maintaining the dep tree ;-) > > - Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
