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.conno...@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 <lud...@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:rg7...@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-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
