Sent from my [rhymes with myPod] ;-)
On 10 May 2009, at 18:01, Stevo Slavić <[email protected]> wrote:
"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 <[email protected]>
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ć <[email protected]>
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 <[email protected]>
wrote:
On Fri, May 8, 2009 at 11:17 AM, Todd Thiessen
<[email protected]>
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
