Mike Perham wrote on Wednesday, August 09, 2006 8:05 PM:
Not exactly. We have a single parent POM per ear and don't
share war/ejbs
between ears, yes. But you can still do what you want with a
dependencyManagement section in the parent to centralize the version
numbers and just have each
I like it and I think that's a reasonable request. Throw it in JIRA and
maybe Santa will deliver it in 2.1. :-)
mike
[EMAIL PROTECTED] wrote on 08/09/2006 11:37:39 PM:
It could define the version conflict resolution rules such that
dependencyManagement version declarations in *my* POMs
Mike Perham wrote on Thursday, August 10, 2006 3:28 PM:
I like it and I think that's a reasonable request. Throw it in JIRA
and maybe Santa will deliver it in 2.1. :-)
This *is* what MNG-1577 is about and it has been postponed since 2.0.1.
:-/
mike
[EMAIL PROTECTED] wrote on
[EMAIL PROTECTED] wrote on 08/10/2006 12:28:36 AM:
If I understand your recommendation correctly, you would like me to
declare
my dependency on version [1.7.0,) instead (meaning version 1.7.0 or
any
later version). From a QE perspective, that is an untestable assertion
--
there is no
Well, I added my vote and +1 to the issue. That's about all I can do since
I shy away from touching the maven core.
mike
Jörg Schaible [EMAIL PROTECTED] wrote on 08/10/2006
08:42:40 AM:
This *is* what MNG-1577 is about and it has been postponed since 2.0.1.
:-/
Hi Craig,
Craig McClanahan wrote on Wednesday, August 09, 2006 6:58 AM:
A project[1] that I'm a participant in is a recent convert to
Maven2 as a
build environment. So far, there's a lot to like. But ... I
think I've run
into a limitation of the current design related to resolving
On 8/8/06, Jörg Schaible [EMAIL PROTECTED] wrote:
Hi Craig,
Hello Jörg
Craig McClanahan wrote on Wednesday, August 09, 2006 6:58 AM:
A project[1] that I'm a participant in is a recent convert to
Maven2 as a
build environment. So far, there's a lot to like. But ... I
think I've run
On 8/8/06, Craig McClanahan [EMAIL PROTECTED] wrote:
Why should I have to declare it in the app, when I've declared it at the
parent level? What's the point of transitive dependencies if they do not
work the way you want, and there's no way to force them to do so?
I should have been more
Hi Craig,
Craig McClanahan wrote on Wednesday, August 09, 2006 8:46 AM:
On 8/8/06, Craig McClanahan [EMAIL PROTECTED] wrote:
Why should I have to declare it in the app, when I've declared it at
the parent level? What's the point of transitive dependencies if
they do not work the way you
Any comment from the maven devs? This problem seems to be affecting more and
more people.
Ruel Loehr
JBoss QA
-Original Message-
From: Jörg Schaible [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 09, 2006 1:57 AM
To: Maven Users List
Subject: RE: Conflicting Dependency Version
We have come up with a pattern that we feel works pretty well to work
around this. We split our modules into standard jars and j2ee type
archives. The standard jars declare their own deps as normal. The j2ee
jars all share a parent which overrides all dependency versions so all the
Hi Mike,
Mike Perham wrote on Wednesday, August 09, 2006 6:21 PM:
We have come up with a pattern that we feel works pretty well to work
around this. We split our modules into standard jars and j2ee type
archives. The standard jars declare their own deps as
normal. The j2ee
jars all share
Not exactly. We have a single parent POM per ear and don't share war/ejbs
between ears, yes. But you can still do what you want with a
dependencyManagement section in the parent to centralize the version
numbers and just have each ear POM pull in its required ejbs. Or am I
missing
On 8/9/06, Mike Perham [EMAIL PROTECTED] wrote:
Not exactly. We have a single parent POM per ear and don't share war/ejbs
between ears, yes. But you can still do what you want with a
dependencyManagement section in the parent to centralize the version
numbers and just have each ear POM pull
Again, this is because dependency B is not using version ranges but rather
forcing a specific version on its downstream dependents.
If A requires a different version, it has to declare that dependency in
order to override the transitive dependency version from B. There's
nothing Maven can do
On 8/9/06, Mike Perham [EMAIL PROTECTED] wrote:
Again, this is because dependency B is not using version ranges but rather
forcing a specific version on its downstream dependents.
Ah, but dependency B is a third party library ... and the entire transitive
dependency tree for Shale (which
On 8/9/06, Mike Perham [EMAIL PROTECTED] wrote:
Again, this is because dependency B is not using version ranges but rather
forcing a specific version on its downstream dependents.
Thinking about this a little further, there is a QE viewpoint that leads me
to believe that declaring a
A project[1] that I'm a participant in is a recent convert to Maven2 as a
build environment. So far, there's a lot to like. But ... I think I've run
into a limitation of the current design related to resolving conflicts in
dependency versions. I'm looking for advice on what I can do other than
18 matches
Mail list logo
