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
> > >
> > >
> >
>

Reply via email to