Jason van Zyl wrote: >>2) scope in end POM always wins >> >> >To me this would seem to be the most obvious the user. > > I agree, given the current use of dependencies.
> > >>4) keep it as is (where you can use <dependencyManagement /> to force >>the appropriate scope) >> >> >Wouldn't that be a little inconvenient and unintuitive to have to create >the <depMan/> element to control the scope of a single dependency. > > Yes, it is inconvenient. A couple of problems with (2): - it changes the behaviour of a dependency contextually when it is acting in transitive mode vs. final POM. This may not be a big deal. - it could hide changes that cause breakages. Consider this scenario: A (a webapp) depends on B (which currently has no dependencies). A depends on commons-collections as a test dependency. B later adds commons-collections as a compile time dependency. Under (4), commons-collections becomes a compile time dependency for A and gets included in the webapp, allowing B to function. Under (2), C-C remains a test dependency for A and gets omitted from the webapp, causing B to fail at runtime with a ClassNotFoundException. Of course, we'd be warning something to the effect of "Dependency scope test commons-collections hides a definition of compile on B", but if that is actually what you wanted to do, doesn't that get annoying? I guess we recommend using depMgmt there to avoid the warning. I guess another option is to use (4) and instead of requiring a depMgmt entry, have a <force>true</force> flag on a dependency? What do others prefer? I guess of all this, I think (2) with the warning might be the best solution. - Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
