Skip to end of metadata
Go to start of metadata

Context

In many environments controlling the exact version of dependencies being used is required. Maven provides support for this through its dependency management support in project descriptors. However, as projects grow in size and begin to incorporate components from other development organizations the current implementation is increasingly difficult to use. This is largely due to the limitation that the only way to incorporate managed dependency declarations from other projects is to incorporate those projects via inheritance.

As an example, consider the following projects:

  1. ThirdParty 1.0 - contains declarations of third party jars.
  2. Project A 1.0 - A project that uses declarations in ThirdParty and produces some number of versioned artifacts.
  3. Project B 1.0 - A project unrelated to Project A. It also uses declarations in ThirdParty and produces some number of versioned artifacts.
  4. Project C 1.0 - Has dependencies on ThirdParty, Project A, and Project B.

In Maven 2 it is not possible for Project C to use the managed dependencies from both A and B since neither has any direct relationship to the other.

Solution

One possible solution would be to simply allow multiple inheritance. However, the negative consequences of allowing that could introduce more problems than it would solve. For example, there might be conflicting report lists or plugin lists in the two parents that would somehow need to be resolved.

A better solution is to allow only the managed dependencies of other projects to be imported as managed dependencies in the current project. For example,

Now when project C is constructed it will incorporate all the managed dependencies declared in the ThirdParty, A, and B bill of materials poms. No other behaviors from these projects will be inherited.  If one assumes that each of ThirdParty, A and B are declaring several artifacts that are being constructed in each of those projects it makes it fairly easy for project C to specify the exact versions of the artifacts it needs without having to copy the definitions from the other projects.

Votes

Please provide comments with your votes.
+1: Ralph Goers
+0:
-1:

  • No labels

2 Comments

  1. -1: I think opening up distributed dependency management is just going to dig ourselves a bigger hole that will very hard to get out of.  I would like to see the use of dependency management decline in preference to using a better conflict resolution strategy (MNG-612), ideally in conjunction with version ranges.

  2. I've created a free, open-source plugin called Assimilate that allows one to import dependencies from other projects without there being a predefined relationship between the two, such as a parent-child relationship. Find it here: http://code.google.com/p/assimilate/

    This import scope that the guys at Apache introduced i'm sure has confused a bunch of people to thinking it does what Assimilate does, only to realize it deals with stuff in the dependency-management section of the pom of the external pom you are trying to deal with. So just to ease that confusion, i invented a plugin (which is also in maven's publically available repository at http://repo1.maven.org/maven2/net/sf/assimilate/assimilate/1.0 ) which does what most developers "think" the import scope does..........just until some other scope comes along (if ever) from Apache that does just that.