maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jieryn (JIRA)" <j...@codehaus.org>
Subject [jira] Created: (MDEP-218) new mojo to move dependencies up/down within multi-module projects
Date Fri, 10 Jul 2009 16:43:22 GMT
new mojo to move dependencies up/down within multi-module projects
------------------------------------------------------------------

                 Key: MDEP-218
                 URL: http://jira.codehaus.org/browse/MDEP-218
             Project: Maven 2.x Dependency Plugin
          Issue Type: New Feature
            Reporter: jieryn
            Assignee: Brian Fox
            Priority: Minor


Brian Fox and I discussed this a bit over IRC today. What I would like to see is two new goals
which will operate on a multi-module project. They both are related in that they move dependency
definitions either to or from an aggregate pom.xml.

Moving dependencies TO aggregate pom from the modules would be the easiest case, and also
the least recommended. This would basically siphon out all of the <dependencies> from
each module's pom, the module list found in aggregate's <modules>, and place them into
the aggregates <dependencies> section. While this isn't really the purist Maven way,
it is a valid way of organizing a pom.xml, and a strategy employed by many users -- and therefore
useful to the population at large.

Moving dependencies FROM aggregate pom to the modules would be a harder, but recommended case.
This would basically run dependency:analyze to determine which dependencies listed in aggregate
pom's <dependencies> section were required in each of the module's pom (again, the module
list found in aggregate's <modules>). Using the analyzed information, it could remove
the aggregate's <dependencies> section and push these dependencies into exactly the
right places.

In both cases we'd end up modifying the pom.xml with the updated dependency information. It
would be wise to mirror the m-release-p behavior of keeping around backup pom.xml documents
for backing out the changes in case of error.

Finally, there's a case where we have multiple levels of depth where an aggregate contains
at least one module which is also an aggregate. I welcome comments, but to me, these enhancements
would operate at a global level in that they'd move dependencies all the way to the root aggregate
or down to the leaf modules, respectively for cases TO and FROM. Also, this only works for
modules which are on the relative file system path -- I often have an aggregate pom whose
parent's is a super pom not located anywhere on my file system. If the system detects this
case, it would consider stop the recursion.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message