On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen <thies...@nortel.com> wrote:
> Override the dependency defined in the POM, as Steve outline in his > earlier response. Let me quote his explanation for ease of reference: > > "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." > > I used the term "override" to descibe the situation when project P > should have LIB1 defined as a compile dependency, when the POM actually > defines it as test. But it should should only override for test > dependencies, not for provided or runtime. > The local pom always wins. Placing additional semantics on how things merge is troublesome. I'm sure we can think of scenarios where widening is not the right thing to do. In either case you must have the ability to resolve this yourself if it doesn't do the right thing...and the way to do that is to put what you want in the local pom. > > As for your "lost me" comment I am not sure what you would like > explained. Scope basically has multiple meanings. Compile/test are both > related to requiring a dependency for compilation; runtime/provided are > both related to requiring a dependency only at runtime. These multiple > meanings are not suited to a single variable. > Are there many cases where you want something for compilation that isn't needed at runtime? I don't see them as being separate. > > --- > Todd Thiessen > >
