2009/5/10 Stevo Slavić <ssla...@gmail.com> > "Just because that's the way things are doesn't mean that's how they should > be.", said a character in the movie "Australia". >
I dig that. > > 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). > At face value the logic seems to make sense, but I haven't thought through all the ramifications. I thought Mark Hobson mentioned some cases where the opposite was desired. At this point your best bet is to prepare a proposal on http://docs.codehaus.org/display/MAVENUSER/User+Proposals with an associated Jira and then start building some consensus around the changes. Work in this area for 3.x is nearing so now's a good time to create the proposal. > > 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 > > > > > > > > > > > > > > > > > > > >
