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]
