You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "GALLAGHER, RON (ATTSI)" <RG...@att.com> on 2010/03/01 21:19:00 UTC
Maven 2.2.1 Dependency Resolution "Issues"
I have a rather complex project which pulls together a large number of
artifacts from other internal projects. The full dependency graph for
this project contains numerous situations where different versions of
the same component are referenced throughout the dependency graph.
Here is a simplified dependency graph that illustrates my situation:
A --> B --> X (1.0)
A --> C --> X (2.0)
In this dependency graph, project A depends on components B and C, both
of which depend on component X. Components B and C depend on different
versions of X. Based on my reading of the "Conflict Resolution" section
on [1], Maven will use version 2.0 of X since it is the "best" and
"nearest" referenced version in my dependency graph.
If my interpretation Maven's dependency conflict resolution is
inaccurate, please clarify and/or correct my interpretation. However,
if my interpretation is correct, then we have a bigger problem in the
project that I'm working on.
A more accurate depiction of the dependency graph for this application
would look something like this:
A --> B --> X (1.0)
A --> C --> X (2.0)
A --> D --> E --> X (3.0)
In this dependency graph, project A still depends on components B and C.
Project A also depends on component D which depends on component E,
which, in turn, depends on a newer version (3.0) of component X. This
dependence on a 'better' version of component X is causing issues for us
when we use the MavenProject.getArtifacts() method to retrieve the
artifacts for project A. If we use the MavenProject.getArtifacts(), we
will end up with an Artifact that references version 2.0 of component X.
Based on my reading of the "Conflict Resolution" section on [1], this is
due to the fact that the reference to version 2.0 of component X is
'nearer' than the reference to version 3.0 of the same component.
It appears that Maven uses the nearest reference to any dependency, and
if two references are equi-distant from the project that's being built,
then Maven uses the 'best' version that is referenced.
In our case, this use of the 'nearest' reference is causing issues at
runtime since version 2.0 of component X does not contain the
functionality of version 3.0. This causes problems
(ClassNotFoundException, NoSuchMethodException) at runtime within
component E.
What we need in this situation is for Maven to ignore the proximity of a
dependency and simply pull in the 'best' version that is referenced,
across the entire dependency graph.
This situation is causing problems with some custom plugins that we have
created. It is also a problem with the dependency plugin since that
plugin uses the same MavenProject.getArtifacts() method to build a list
of all project dependencies. "Problem" probably isn't the best word
choice here. Let's just say that the behavior exhibited by these
plugins (both our internal plugins and the dependency plugin) is not
what we would like to see.
So, here are some questions...
Q1. Is there a mechanism within Maven that would provide a list of the
the 'best' dependency references within a project's dependency graph?
Q2. Is this something that would be useful to the community? (I already
have a solution available)
Q3. If the answer to Q2 is Yes, then which project should I create a
Jira issue for and submit a patch with the mechanism?
For reference, all builds are running under Maven 2.2.1.
Ron Gallagher
[1]
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict
+Resolution
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Maven 2.2.1 Dependency Resolution "Issues"
Posted by "GALLAGHER, RON (ATTSI)" <RG...@att.com>.
Yes, that would solve this problem. However, that approach is not an
option.
I also know that I could add an entry to the dependencyManagement
section of project A to address this situation. However, due to other
requirements of this project, the use of a dependencyManagement entry is
not a viable option either.
Ron Gallagher
-----Original Message-----
From: Ludwig Magnusson [mailto:ludwig@itcatapult.com]
Sent: Monday, March 01, 2010 3:26 PM
To: 'Maven Users List'
Subject: RE: Maven 2.2.1 Dependency Resolution "Issues"
Isn't it enough to just let A depend on X(3.0)?
It would solve this particular problem but perhaps there are other more
complex?
/Ludwig
-----Original Message-----
From: GALLAGHER, RON (ATTSI) [mailto:RG7679@att.com]
Sent: den 1 mars 2010 21:19
To: Mailing List - Maven Users
Subject: Maven 2.2.1 Dependency Resolution "Issues"
I have a rather complex project which pulls together a large number of
artifacts from other internal projects. The full dependency graph for
this project contains numerous situations where different versions of
the same component are referenced throughout the dependency graph.
Here is a simplified dependency graph that illustrates my situation:
A --> B --> X (1.0)
A --> C --> X (2.0)
In this dependency graph, project A depends on components B and C, both
of which depend on component X. Components B and C depend on different
versions of X. Based on my reading of the "Conflict Resolution" section
on [1], Maven will use version 2.0 of X since it is the "best" and
"nearest" referenced version in my dependency graph.
If my interpretation Maven's dependency conflict resolution is
inaccurate, please clarify and/or correct my interpretation. However,
if my interpretation is correct, then we have a bigger problem in the
project that I'm working on.
A more accurate depiction of the dependency graph for this application
would look something like this:
A --> B --> X (1.0)
A --> C --> X (2.0)
A --> D --> E --> X (3.0)
In this dependency graph, project A still depends on components B and C.
Project A also depends on component D which depends on component E,
which, in turn, depends on a newer version (3.0) of component X. This
dependence on a 'better' version of component X is causing issues for us
when we use the MavenProject.getArtifacts() method to retrieve the
artifacts for project A. If we use the MavenProject.getArtifacts(), we
will end up with an Artifact that references version 2.0 of component X.
Based on my reading of the "Conflict Resolution" section on [1], this is
due to the fact that the reference to version 2.0 of component X is
'nearer' than the reference to version 3.0 of the same component.
It appears that Maven uses the nearest reference to any dependency, and
if two references are equi-distant from the project that's being built,
then Maven uses the 'best' version that is referenced.
In our case, this use of the 'nearest' reference is causing issues at
runtime since version 2.0 of component X does not contain the
functionality of version 3.0. This causes problems
(ClassNotFoundException, NoSuchMethodException) at runtime within
component E.
What we need in this situation is for Maven to ignore the proximity of a
dependency and simply pull in the 'best' version that is referenced,
across the entire dependency graph.
This situation is causing problems with some custom plugins that we have
created. It is also a problem with the dependency plugin since that
plugin uses the same MavenProject.getArtifacts() method to build a list
of all project dependencies. "Problem" probably isn't the best word
choice here. Let's just say that the behavior exhibited by these
plugins (both our internal plugins and the dependency plugin) is not
what we would like to see.
So, here are some questions...
Q1. Is there a mechanism within Maven that would provide a list of the
the 'best' dependency references within a project's dependency graph?
Q2. Is this something that would be useful to the community? (I already
have a solution available)
Q3. If the answer to Q2 is Yes, then which project should I create a
Jira issue for and submit a patch with the mechanism?
For reference, all builds are running under Maven 2.2.1.
Ron Gallagher
[1]
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict
+Resolution
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven 2.2.1 Dependency Resolution "Issues"
Posted by Ron Wheeler <rw...@artifact-software.com>.
If you are willing to force B and C to use X (3.0) anyway if they are
packaged with D, then why not just settle on version 3.0 as the
supported version of X.
It seems that X has to be upwards compatible anyway and if it is not
going to be upwards compatible then you need to create a new library
X-Prime that can not be substituted for X (2.0) or X (1.0).
Ron
GALLAGHER, RON (ATTSI) wrote:
> I know that the dependencyManagement section could solve this. However,
> there are other requirements of this project that make that solution
> unsuitable. The main requirement is that the final packaging of the
> components of this application is configurable by users. Users select
> the components (A, B and/or C) that they want in each package, and based
> on those selections, we mechanically create POM files that represent the
> desired packaging.
>
> Users could configure package P1 with components B and D, and package P2
> with component C.
>
> P1 --> B --> X (1.0)
> P1 --> D --> E --> X (3.0)
>
> P2 --> C --> X (2.0)
>
> In this scenario, package P 1 would contain version 3.0 of X and package
> 2 would contain version 2.0.
>
> The dependency graph that I've presented is greatly simplified from the
> reality that I am dealing with. In reality, there are about 6 or 7
> 'hops' between the component that's selected for inclusion in a package
> (A) and the artifact that's causing issues (X). Due to the distance
> between the package (package P1) and component X, the use of
> dependencyManagement really is not a viable approach.
>
> Ron Gallagher
>
> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> Sent: Monday, March 01, 2010 4:19 PM
> To: Maven Users List
> Subject: Re: Maven 2.2.1 Dependency Resolution "Issues"
>
> You could alwas se depenencyMnagement setion to lock down the version
>
> On 1 March 2010 20:26, Ludwig Magnusson <lu...@itcatapult.com> wrote:
>
>
>> Isn't it enough to just let A depend on X(3.0)?
>> It would solve this particular problem but perhaps there are other
>>
> more
>
>> complex?
>> /Ludwig
>>
>> -----Original Message-----
>> From: GALLAGHER, RON (ATTSI) [mailto:RG7679@att.com]
>> Sent: den 1 mars 2010 21:19
>> To: Mailing List - Maven Users
>> Subject: Maven 2.2.1 Dependency Resolution "Issues"
>>
>> I have a rather complex project which pulls together a large number of
>> artifacts from other internal projects. The full dependency graph for
>> this project contains numerous situations where different versions of
>> the same component are referenced throughout the dependency graph.
>>
>> Here is a simplified dependency graph that illustrates my situation:
>>
>> A --> B --> X (1.0)
>> A --> C --> X (2.0)
>>
>> In this dependency graph, project A depends on components B and C,
>>
> both
>
>> of which depend on component X. Components B and C depend on
>>
> different
>
>> versions of X. Based on my reading of the "Conflict Resolution"
>>
> section
>
>> on [1], Maven will use version 2.0 of X since it is the "best" and
>> "nearest" referenced version in my dependency graph.
>>
>> If my interpretation Maven's dependency conflict resolution is
>> inaccurate, please clarify and/or correct my interpretation. However,
>> if my interpretation is correct, then we have a bigger problem in the
>> project that I'm working on.
>>
>> A more accurate depiction of the dependency graph for this application
>> would look something like this:
>>
>> A --> B --> X (1.0)
>> A --> C --> X (2.0)
>> A --> D --> E --> X (3.0)
>>
>> In this dependency graph, project A still depends on components B and
>>
> C.
>
>> Project A also depends on component D which depends on component E,
>> which, in turn, depends on a newer version (3.0) of component X. This
>> dependence on a 'better' version of component X is causing issues for
>>
> us
>
>> when we use the MavenProject.getArtifacts() method to retrieve the
>> artifacts for project A. If we use the MavenProject.getArtifacts(), we
>> will end up with an Artifact that references version 2.0 of component
>>
> X.
>
>> Based on my reading of the "Conflict Resolution" section on [1], this
>>
> is
>
>> due to the fact that the reference to version 2.0 of component X is
>> 'nearer' than the reference to version 3.0 of the same component.
>>
>> It appears that Maven uses the nearest reference to any dependency,
>>
> and
>
>> if two references are equi-distant from the project that's being
>>
> built,
>
>> then Maven uses the 'best' version that is referenced.
>>
>> In our case, this use of the 'nearest' reference is causing issues at
>> runtime since version 2.0 of component X does not contain the
>> functionality of version 3.0. This causes problems
>> (ClassNotFoundException, NoSuchMethodException) at runtime within
>> component E.
>>
>> What we need in this situation is for Maven to ignore the proximity of
>>
> a
>
>> dependency and simply pull in the 'best' version that is referenced,
>> across the entire dependency graph.
>>
>> This situation is causing problems with some custom plugins that we
>>
> have
>
>> created. It is also a problem with the dependency plugin since that
>> plugin uses the same MavenProject.getArtifacts() method to build a
>>
> list
>
>> of all project dependencies. "Problem" probably isn't the best word
>> choice here. Let's just say that the behavior exhibited by these
>> plugins (both our internal plugins and the dependency plugin) is not
>> what we would like to see.
>>
>> So, here are some questions...
>>
>> Q1. Is there a mechanism within Maven that would provide a list of the
>> the 'best' dependency references within a project's dependency graph?
>> Q2. Is this something that would be useful to the community? (I
>>
> already
>
>> have a solution available)
>> Q3. If the answer to Q2 is Yes, then which project should I create a
>> Jira issue for and submit a patch with the mechanism?
>>
>> For reference, all builds are running under Maven 2.2.1.
>>
>> Ron Gallagher
>>
>> [1]
>>
>>
> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict
>
>> +Resolution
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Maven 2.2.1 Dependency Resolution "Issues"
Posted by "GALLAGHER, RON (ATTSI)" <RG...@att.com>.
I know that the dependencyManagement section could solve this. However,
there are other requirements of this project that make that solution
unsuitable. The main requirement is that the final packaging of the
components of this application is configurable by users. Users select
the components (A, B and/or C) that they want in each package, and based
on those selections, we mechanically create POM files that represent the
desired packaging.
Users could configure package P1 with components B and D, and package P2
with component C.
P1 --> B --> X (1.0)
P1 --> D --> E --> X (3.0)
P2 --> C --> X (2.0)
In this scenario, package P 1 would contain version 3.0 of X and package
2 would contain version 2.0.
The dependency graph that I've presented is greatly simplified from the
reality that I am dealing with. In reality, there are about 6 or 7
'hops' between the component that's selected for inclusion in a package
(A) and the artifact that's causing issues (X). Due to the distance
between the package (package P1) and component X, the use of
dependencyManagement really is not a viable approach.
Ron Gallagher
-----Original Message-----
From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
Sent: Monday, March 01, 2010 4:19 PM
To: Maven Users List
Subject: Re: Maven 2.2.1 Dependency Resolution "Issues"
You could alwas se depenencyMnagement setion to lock down the version
On 1 March 2010 20:26, Ludwig Magnusson <lu...@itcatapult.com> wrote:
> Isn't it enough to just let A depend on X(3.0)?
> It would solve this particular problem but perhaps there are other
more
> complex?
> /Ludwig
>
> -----Original Message-----
> From: GALLAGHER, RON (ATTSI) [mailto:RG7679@att.com]
> Sent: den 1 mars 2010 21:19
> To: Mailing List - Maven Users
> Subject: Maven 2.2.1 Dependency Resolution "Issues"
>
> I have a rather complex project which pulls together a large number of
> artifacts from other internal projects. The full dependency graph for
> this project contains numerous situations where different versions of
> the same component are referenced throughout the dependency graph.
>
> Here is a simplified dependency graph that illustrates my situation:
>
> A --> B --> X (1.0)
> A --> C --> X (2.0)
>
> In this dependency graph, project A depends on components B and C,
both
> of which depend on component X. Components B and C depend on
different
> versions of X. Based on my reading of the "Conflict Resolution"
section
> on [1], Maven will use version 2.0 of X since it is the "best" and
> "nearest" referenced version in my dependency graph.
>
> If my interpretation Maven's dependency conflict resolution is
> inaccurate, please clarify and/or correct my interpretation. However,
> if my interpretation is correct, then we have a bigger problem in the
> project that I'm working on.
>
> A more accurate depiction of the dependency graph for this application
> would look something like this:
>
> A --> B --> X (1.0)
> A --> C --> X (2.0)
> A --> D --> E --> X (3.0)
>
> In this dependency graph, project A still depends on components B and
C.
> Project A also depends on component D which depends on component E,
> which, in turn, depends on a newer version (3.0) of component X. This
> dependence on a 'better' version of component X is causing issues for
us
> when we use the MavenProject.getArtifacts() method to retrieve the
> artifacts for project A. If we use the MavenProject.getArtifacts(), we
> will end up with an Artifact that references version 2.0 of component
X.
> Based on my reading of the "Conflict Resolution" section on [1], this
is
> due to the fact that the reference to version 2.0 of component X is
> 'nearer' than the reference to version 3.0 of the same component.
>
> It appears that Maven uses the nearest reference to any dependency,
and
> if two references are equi-distant from the project that's being
built,
> then Maven uses the 'best' version that is referenced.
>
> In our case, this use of the 'nearest' reference is causing issues at
> runtime since version 2.0 of component X does not contain the
> functionality of version 3.0. This causes problems
> (ClassNotFoundException, NoSuchMethodException) at runtime within
> component E.
>
> What we need in this situation is for Maven to ignore the proximity of
a
> dependency and simply pull in the 'best' version that is referenced,
> across the entire dependency graph.
>
> This situation is causing problems with some custom plugins that we
have
> created. It is also a problem with the dependency plugin since that
> plugin uses the same MavenProject.getArtifacts() method to build a
list
> of all project dependencies. "Problem" probably isn't the best word
> choice here. Let's just say that the behavior exhibited by these
> plugins (both our internal plugins and the dependency plugin) is not
> what we would like to see.
>
> So, here are some questions...
>
> Q1. Is there a mechanism within Maven that would provide a list of the
> the 'best' dependency references within a project's dependency graph?
> Q2. Is this something that would be useful to the community? (I
already
> have a solution available)
> Q3. If the answer to Q2 is Yes, then which project should I create a
> Jira issue for and submit a patch with the mechanism?
>
> For reference, all builds are running under Maven 2.2.1.
>
> Ron Gallagher
>
> [1]
>
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict
> +Resolution
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven 2.2.1 Dependency Resolution "Issues"
Posted by Stephen Connolly <st...@gmail.com>.
You could alwas se depenencyMnagement setion to lock down the version
On 1 March 2010 20:26, Ludwig Magnusson <lu...@itcatapult.com> wrote:
> Isn't it enough to just let A depend on X(3.0)?
> It would solve this particular problem but perhaps there are other more
> complex?
> /Ludwig
>
> -----Original Message-----
> From: GALLAGHER, RON (ATTSI) [mailto:RG7679@att.com]
> Sent: den 1 mars 2010 21:19
> To: Mailing List - Maven Users
> Subject: Maven 2.2.1 Dependency Resolution "Issues"
>
> I have a rather complex project which pulls together a large number of
> artifacts from other internal projects. The full dependency graph for
> this project contains numerous situations where different versions of
> the same component are referenced throughout the dependency graph.
>
> Here is a simplified dependency graph that illustrates my situation:
>
> A --> B --> X (1.0)
> A --> C --> X (2.0)
>
> In this dependency graph, project A depends on components B and C, both
> of which depend on component X. Components B and C depend on different
> versions of X. Based on my reading of the "Conflict Resolution" section
> on [1], Maven will use version 2.0 of X since it is the "best" and
> "nearest" referenced version in my dependency graph.
>
> If my interpretation Maven's dependency conflict resolution is
> inaccurate, please clarify and/or correct my interpretation. However,
> if my interpretation is correct, then we have a bigger problem in the
> project that I'm working on.
>
> A more accurate depiction of the dependency graph for this application
> would look something like this:
>
> A --> B --> X (1.0)
> A --> C --> X (2.0)
> A --> D --> E --> X (3.0)
>
> In this dependency graph, project A still depends on components B and C.
> Project A also depends on component D which depends on component E,
> which, in turn, depends on a newer version (3.0) of component X. This
> dependence on a 'better' version of component X is causing issues for us
> when we use the MavenProject.getArtifacts() method to retrieve the
> artifacts for project A. If we use the MavenProject.getArtifacts(), we
> will end up with an Artifact that references version 2.0 of component X.
> Based on my reading of the "Conflict Resolution" section on [1], this is
> due to the fact that the reference to version 2.0 of component X is
> 'nearer' than the reference to version 3.0 of the same component.
>
> It appears that Maven uses the nearest reference to any dependency, and
> if two references are equi-distant from the project that's being built,
> then Maven uses the 'best' version that is referenced.
>
> In our case, this use of the 'nearest' reference is causing issues at
> runtime since version 2.0 of component X does not contain the
> functionality of version 3.0. This causes problems
> (ClassNotFoundException, NoSuchMethodException) at runtime within
> component E.
>
> What we need in this situation is for Maven to ignore the proximity of a
> dependency and simply pull in the 'best' version that is referenced,
> across the entire dependency graph.
>
> This situation is causing problems with some custom plugins that we have
> created. It is also a problem with the dependency plugin since that
> plugin uses the same MavenProject.getArtifacts() method to build a list
> of all project dependencies. "Problem" probably isn't the best word
> choice here. Let's just say that the behavior exhibited by these
> plugins (both our internal plugins and the dependency plugin) is not
> what we would like to see.
>
> So, here are some questions...
>
> Q1. Is there a mechanism within Maven that would provide a list of the
> the 'best' dependency references within a project's dependency graph?
> Q2. Is this something that would be useful to the community? (I already
> have a solution available)
> Q3. If the answer to Q2 is Yes, then which project should I create a
> Jira issue for and submit a patch with the mechanism?
>
> For reference, all builds are running under Maven 2.2.1.
>
> Ron Gallagher
>
> [1]
> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict
> +Resolution
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: Maven 2.2.1 Dependency Resolution "Issues"
Posted by Ludwig Magnusson <lu...@itcatapult.com>.
Isn't it enough to just let A depend on X(3.0)?
It would solve this particular problem but perhaps there are other more
complex?
/Ludwig
-----Original Message-----
From: GALLAGHER, RON (ATTSI) [mailto:RG7679@att.com]
Sent: den 1 mars 2010 21:19
To: Mailing List - Maven Users
Subject: Maven 2.2.1 Dependency Resolution "Issues"
I have a rather complex project which pulls together a large number of
artifacts from other internal projects. The full dependency graph for
this project contains numerous situations where different versions of
the same component are referenced throughout the dependency graph.
Here is a simplified dependency graph that illustrates my situation:
A --> B --> X (1.0)
A --> C --> X (2.0)
In this dependency graph, project A depends on components B and C, both
of which depend on component X. Components B and C depend on different
versions of X. Based on my reading of the "Conflict Resolution" section
on [1], Maven will use version 2.0 of X since it is the "best" and
"nearest" referenced version in my dependency graph.
If my interpretation Maven's dependency conflict resolution is
inaccurate, please clarify and/or correct my interpretation. However,
if my interpretation is correct, then we have a bigger problem in the
project that I'm working on.
A more accurate depiction of the dependency graph for this application
would look something like this:
A --> B --> X (1.0)
A --> C --> X (2.0)
A --> D --> E --> X (3.0)
In this dependency graph, project A still depends on components B and C.
Project A also depends on component D which depends on component E,
which, in turn, depends on a newer version (3.0) of component X. This
dependence on a 'better' version of component X is causing issues for us
when we use the MavenProject.getArtifacts() method to retrieve the
artifacts for project A. If we use the MavenProject.getArtifacts(), we
will end up with an Artifact that references version 2.0 of component X.
Based on my reading of the "Conflict Resolution" section on [1], this is
due to the fact that the reference to version 2.0 of component X is
'nearer' than the reference to version 3.0 of the same component.
It appears that Maven uses the nearest reference to any dependency, and
if two references are equi-distant from the project that's being built,
then Maven uses the 'best' version that is referenced.
In our case, this use of the 'nearest' reference is causing issues at
runtime since version 2.0 of component X does not contain the
functionality of version 3.0. This causes problems
(ClassNotFoundException, NoSuchMethodException) at runtime within
component E.
What we need in this situation is for Maven to ignore the proximity of a
dependency and simply pull in the 'best' version that is referenced,
across the entire dependency graph.
This situation is causing problems with some custom plugins that we have
created. It is also a problem with the dependency plugin since that
plugin uses the same MavenProject.getArtifacts() method to build a list
of all project dependencies. "Problem" probably isn't the best word
choice here. Let's just say that the behavior exhibited by these
plugins (both our internal plugins and the dependency plugin) is not
what we would like to see.
So, here are some questions...
Q1. Is there a mechanism within Maven that would provide a list of the
the 'best' dependency references within a project's dependency graph?
Q2. Is this something that would be useful to the community? (I already
have a solution available)
Q3. If the answer to Q2 is Yes, then which project should I create a
Jira issue for and submit a patch with the mechanism?
For reference, all builds are running under Maven 2.2.1.
Ron Gallagher
[1]
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict
+Resolution
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org