Is there any reason why would local win in this particular case? Regards, Stevo.
On Sun, May 10, 2009 at 5:26 AM, Brian Fox <bri...@infinity.nu> wrote: > 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 > > > > >
