Brian Fox schrieb:
On Mon, May 11, 2009 at 9:48 AM, Todd Thiessen thies...@nortel.com wrote:
Are there many cases where you want something for compilation
that isn't needed at runtime? I don't see them as being separate.
Really? I am surprised. Yes there is a relation between compile and
On Mon, May 11, 2009 at 9:48 AM, Todd Thiessen thies...@nortel.com wrote:
Are there many cases where you want something for compilation
that isn't needed at runtime? I don't see them as being separate.
Really? I am surprised. Yes there is a relation between compile and
runtime. However,
At test runtime I presume? You use the test scope. Is it
hurting anything if it's there on the test compile classpath?
Its an example of how the scope definition is overloaded. Whether or not
it hurts anything is moot.
-
To
Hi,
After inheritance, the war dependency tree looks like this:
foo.bar:b:war:0.0.1-SNAPSHOT
+- org.apache.velocity:velocity:jar:1.6.2:test
\- foo.bar:a:jar:0.0.1-SNAPSHOT:compile
+- org.apache.velocity:velocity:jar:1.6.2:test
\- org.apache.velocity:velocity:jar:1.6.2:compile
So the
Are there many cases where you want something for compilation
that isn't needed at runtime? I don't see them as being separate.
Really? I am surprised. Yes there is a relation between compile and
runtime. However, there is a different relation between compile and
test. Scope has multiple
you may have a valid reason for so doing, but maven is no
medium and cannot ask a higher plain what you wanted to do.
It doesn't need to. Maven has all the information. If a transitive
dependency has compile scope it should never get demoted to test scope.
However, you do want it to get
2009/5/11 Todd Thiessen thies...@nortel.com
Are there many cases where you want something for compilation
that isn't needed at runtime? I don't see them as being separate.
Really? I am surprised. Yes there is a relation between compile and
runtime. However, there is a different relation
2009/5/11 Todd Thiessen thies...@nortel.com
you may have a valid reason for so doing, but maven is no
medium and cannot ask a higher plain what you wanted to do.
It doesn't need to. Maven has all the information. If a transitive
dependency has compile scope it should never get demoted to
I think the answer here is that nobody had a good example at the
time!
And even when you do, you can use exclusions which you interesting
mention in your next response ;-). So if you want a particular compile
transitive dependency to be included only as test, exclude it and add it
to your local
2009/5/11 Todd Thiessen thies...@nortel.com
I think the answer here is that nobody had a good example at the
time!
And even when you do, you can use exclusions which you interesting
mention in your next response ;-). So if you want a particular compile
transitive dependency to be included
2009/5/11 Brian Fox bri...@infinity.nu:
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
Just created http://jira.codehaus.org/browse/MNG-4156
Regards,
Stevo.
On Mon, May 11, 2009 at 6:40 PM, Mark Hobson markhob...@gmail.com wrote:
2009/5/11 Brian Fox bri...@infinity.nu:
At face value the logic seems to make sense, but I haven't thought
through
all the ramifications. I
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
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
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
Sent from my [rhymes with myPod] ;-)
On 10 May 2009, at 18:01, Stevo Slavić ssla...@gmail.com 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
IIRC maven warns you that you have changed a dependency from compile
scope to test scope.
you may have a valid reason for so doing, but maven is no medium and
cannot ask a higher plain what you wanted to do. if a warning is not
good enough, tough
Sent from my [rhymes with myPod] ;-)
On
One can package, install and deploy such a war, no warning related to this
issue will get printed.
Regards,
Stevo.
On Sun, May 10, 2009 at 8:57 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
IIRC maven warns you that you have changed a dependency from compile scope
to test
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
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
This is really a symptom of the nearest-wins mentality of Maven 2,
since scopes specified in the current POM take precedence over their
transitive values, and not widened as expected. AFAIK Mercury will
replace nearest-wins version conflict resolution with a more usable
highest-wins, so I was
Mark Hobson wrote at Freitag, 8. Mai 2009 11:05:
This is really a symptom of the nearest-wins mentality of Maven 2,
since scopes specified in the current POM take precedence over their
transitive values, and not widened as expected. AFAIK Mercury will
replace nearest-wins version conflict
Issue is elsewhere. Initial example I gave included inheritance, but
unwanted behavior happens even without it.
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
Hi Stevo,
Stevo Slavić wrote at Freitag, 8. Mai 2009 14:15:
Issue is elsewhere. Initial example I gave included inheritance, but
unwanted behavior happens even without it.
E.g. if project P has test scoped dependency to a LIB1, and compile scoped
dependency to LIB2, while LIB2 has compile
Your argument Jorg I think applies to provided and runtime scope, but not to
test.
The root smell here lies in the definition of scope. Test scope means needed
to compile test code. Compile scope means needed to compile production and test
code. These are both related to when a dependency is
2009/5/8 Todd Thiessen thies...@nortel.com
Your argument Jorg I think applies to provided and runtime scope, but not
to test.
The root smell here lies in the definition of scope. Test scope means
needed to compile test code. Compile scope means needed to compile
production and test code.
2009/5/8 Jörg Schaible joerg.schai...@gmx.de:
This would be the show stopper for me for ever using Mercury. If I narrow
the scope in the local POM it is done *because I want it so*, e.g.
preventing compile time deps to a specific implementation that's hidden
behind an interface.
This should
2009/5/8 Jörg Schaible joerg.schai...@gmx.de:
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.
This is the whole point: This is
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
I think this will help you understand it better:
Think of inheritance as including the contents of the parents inside your
own pom. (obviously merging occurs). I used to be a C programmer so I refer
to this as #include-ing the contents.
Therefore the result of inheritance is that it updates your
When I run your example with mvn dependency:tree this is what I get:
[INFO] [dependency:tree]
[INFO] foo.bar:foo-bar-parent:pom:0.0.1-SNAPSHOT
[INFO] \- org.apache.velocity:velocity:jar:1.6.2:test
[INFO]+- commons-collections:commons-collections:jar:3.2.1:test
[INFO]+-
When I run mvn dependency:resolve the output explains something more.
(Ran it with debug on)
[INFO]
[INFO] Building Unnamed - foo.bar:b:war:0.0.1-SNAPSHOT
[INFO]task-segment: [dependency:resolve]
[INFO]
Thanks Nick for quick reply!
Shouldn't broader scope win over narrower one, at least in this specific
scenario?
Regards,
Stevo.
On Wed, May 6, 2009 at 11:40 AM, Nick Stolwijk nick.stolw...@gmail.comwrote:
When I run mvn dependency:resolve the output explains something more.
(Ran it with
Warning (dependency:resolve printed) that broader scope has been overridden
doesn't even print when one packages project...
Regards,
Stevo.
2009/5/6 Stevo Slavić ssla...@gmail.com
Thanks Nick for quick reply!
Shouldn't broader scope win over narrower one, at least in this specific
scenario?
Greater problem here is that tests would run fine (except functional tests,
if there are any, that would actually deploy/run war), and one could
discover dependency is missing only at runtime...
Regards,
Stevo.
2009/5/6 Stevo Slavić ssla...@gmail.com
Warning (dependency:resolve printed) that
After inheritance, the war dependency tree looks like this:
foo.bar:b:war:0.0.1-SNAPSHOT
+- org.apache.velocity:velocity:jar:1.6.2:test
\- foo.bar:a:jar:0.0.1-SNAPSHOT:compile
+- org.apache.velocity:velocity:jar:1.6.2:test
\- org.apache.velocity:velocity:jar:1.6.2:compile
So the resolved
36 matches
Mail list logo
