"Just because that's the way things are doesn't mean that's how they should be.", said a character in the movie "Australia".
In this particular scenario, local test scoped dependency vs compile scope transitive dependency, it's my opinion that current strategy is wrong. Local test scoped dependencies shouldn't by default override compile scoped transitive dependencies. If one wanted to exclude transitive compile scoped dependency and have it available only in test scope, it would be more natural (for me at least) to require user to specify appropriate excludes section on a dependency that brought transitive dependency with it. Again, just in this particular case, requiring user to explicitly specify excludes section would more clearly state/document the intention, while currently build tool silently makes a wrong decision (maybe there are times this decision is correct, but IMO it correct in far less cases than it is wrong). Regards, Stevo. 2009/5/10 Brian Fox <bri...@infinity.nu> > By local I mean the pom currently being built. Stuff defined here always > overrides dependencies and transitive dependencies. > > On Sun, May 10, 2009 at 5:34 AM, Stevo Slavić <ssla...@gmail.com> wrote: > > > 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 > > > > > > > > > > > > > >
