Terrific - Thanks for the update. I put in votes on
both :-)
Cheers,
- Ole
--- Stephen Duncan <[EMAIL PROTECTED]> wrote:
> Yes, this is a known issue. See
> http://jira.codehaus.org/browse/MECLIPSE-107 and
> http://jira.codehaus.org/browse/MNG-2340
>
> -Stephen
>
> On 12/3/06, Ole Ersoy <[EM
This is a long standing and popular issue in JIRA.
On 12/3/06, Ole Ersoy <[EMAIL PROTECTED]> wrote:
Hi,
If I override a dependency
in a child pom, and then
run
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional comma
Yes, this is a known issue. See
http://jira.codehaus.org/browse/MECLIPSE-107 and
http://jira.codehaus.org/browse/MNG-2340
-Stephen
On 12/3/06, Ole Ersoy <[EMAIL PROTECTED]> wrote:
Hi,
If I override a dependency
in a child pom, and then
run
mvn eclipse:eclipse
in the child project directory
On 15 Sep 06, at 4:06 PM 15 Sep 06, Ralph Goers wrote:
OK. Could someone apply the patch I provided for http://
jira.codehaus.org/browse/MNG-1577 and verify it?
If you add tests I will apply it. I don't have time to check it and
verify it right now. A test would expedite the review of thi
OK. Could someone apply the patch I provided for
http://jira.codehaus.org/browse/MNG-1577 and verify it?
Ralph
Carlos Sanchez wrote:
Is not that we don't want to see that fixed, but we're very busy. A
patch would help to get it solved earlier.
---
Is not that we don't want to see that fixed, but we're very busy. A
patch would help to get it solved earlier.
On 2/28/06, Ralph Goers <[EMAIL PROTECTED]> wrote:
> OK. Thanks for the info. But until
> http://jira.codehaus.org/browse/MNG-1577 is fixed I'm afraid I will have
> to stick with Maven 1.
OK. Thanks for the info. But until
http://jira.codehaus.org/browse/MNG-1577 is fixed I'm afraid I will have
to stick with Maven 1.0.2. FWIW, the vote count on that issue has gone
from 3 to 8 since I started this thread yesterday. I guarantee it will
go much higher.
Carlos Sanchez wrote:
Y
You don't have guarantee of wich one will be chosen, althoug it will
be always the same.
On 2/28/06, Ralph Goers <[EMAIL PROTECTED]> wrote:
> And if A -> B -> D1.0 and
>-> C -> D2.0
> who wins?
>
>
> Carlos Sanchez said:
> > No, closest in the dependency graph means that the deepes
And if A -> B -> D1.0 and
-> C -> D2.0
who wins?
Carlos Sanchez said:
> No, closest in the dependency graph means that the deepest dep is
> overriden
>
> If A -> B -> C1.0 and A -> C2.0
> then C2.0 wins because id closer to your project (A)
>
> On 2/28/06, Ralph Goers <[EMAIL PROTE
No, closest in the dependency graph means that the deepest dep is overriden
If A -> B -> C1.0 and A -> C2.0
then C2.0 wins because id closer to your project (A)
On 2/28/06, Ralph Goers <[EMAIL PROTECTED]> wrote:
> Carlos Sanchez said:
> > To be clear:
> > You never have two artifacts in the class
Carlos Sanchez said:
> To be clear:
> You never have two artifacts in the classpath with same
> groupId:artifactId, maven uses the "nearer" version always, which is
> the one closest to your project in the transitive dependency graph,
> not the most recent version.
Is that the same as saying it us
To be clear:
You never have two artifacts in the classpath with same
groupId:artifactId, maven uses the "nearer" version always, which is
the one closest to your project in the transitive dependency graph,
not the most recent version.
On 2/28/06, Steve Loughran <[EMAIL PROTECTED]> wrote:
> Ralph G
Eric Redmond said:
> On 2/28/06, Ralph Goers <[EMAIL PROTECTED]> wrote:
>>
>>
>> If this is truly the way it works than it certainly can't be claimed
>> that Maven supports transitive dependencies as they will almost always
>> have to be bypassed. For example, if project A includes myfaces 1.1.1 it
On 2/28/06, Ralph Goers <[EMAIL PROTECTED]> wrote:
>
> Steve,
>
> What you are proposing is to basically bypass maven and "hack" the pom's
> dynamically with the versions required. It seems to me it would be
> easier to have a process to do that in one's local repository. Then you
> only have to d
Steve Loughran wrote:
No. I have a properties file that lays down the dependencies for
everything in my project, like log4j, across
about 20 different sub projects.
These have template pom files that hard code what they depend on, but
the actual version of what they depend on is driven by my
Ralph Goers wrote:
Steve,
What you are proposing is to basically bypass maven and "hack" the pom's
dynamically with the versions required. It seems to me it would be
easier to have a process to do that in one's local repository. Then you
only have to do it once. But then you don't have a re
Steve,
What you are proposing is to basically bypass maven and "hack" the pom's
dynamically with the versions required. It seems to me it would be
easier to have a process to do that in one's local repository. Then you
only have to do it once. But then you don't have a real copy of what is
Ralph Goers wrote:
If I read you right, then I have to treat Maven 2 as if it is Maven 1
and self-discover what all my project's runtime dependencies are going
to be?
Our configuration management dept requires that all our projects use the
same versions of xerces, xalan, etc. This is controlle
Thanks. I guess I'm not the first to feel this is a major design error.
Carlos Sanchez wrote:
You can vote for the issue http://jira.codehaus.org/browse/MNG-1577
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For addition
If I read you right, then I have to treat Maven 2 as if it is Maven 1
and self-discover what all my project's runtime dependencies are going
to be?
Our configuration management dept requires that all our projects use the
same versions of xerces, xalan, etc. This is controlled via the
build.p
Just put the dependency in your own POM when you need to force that
version, and the dependency management will be applied.
The dependency management is not applied to transitive dependencies, but
removing the version in the repository won't change that (they'd just
fail instead).
- Brett
Ralph
You can vote for the issue http://jira.codehaus.org/browse/MNG-1577
On 2/27/06, Ralph Goers <[EMAIL PROTECTED]> wrote:
> We have been using Maven 1 for all our projects. We have a master
> build.properties file that contains the version of every dependency we
> use throughout all of our projects.
22 matches
Mail list logo
