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:[email protected]]
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 <[email protected]> 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:[email protected]]
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
