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] > >
