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. 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. 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... :) ). Regards, Stevo. On Fri, May 8, 2009 at 1:43 PM, Jörg Schaible <[email protected]> wrote: > Mark Hobson wrote at Freitag, 8. Mai 2009 11:05: > > > This is really a symptom of the nearest-wins mentality of Maven 2, > > since scopes specified in the current POM take precedence over their > > transitive values, and not widened as expected. AFAIK Mercury will > > replace nearest-wins version conflict resolution with a more usable > > highest-wins, so I was hoping that it'd also take a similar approach > > with scope conflicts and always widen them, irrespective of where they > > are defined. Perhaps Oleg could clarify? > > This would be the show stopper for me for ever using Mercury. If I narrow > the scope in the local POM it is done *because I want it so*, e.g. > preventing compile time deps to a specific implementation that's hidden > behind an interface. > > - Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
