[
https://jira.codehaus.org/browse/MDEP-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MDEP-218.
-------------------------------
Resolution: Won't Fix
Assignee: Robert Scholte
The dependency plugin is primarily meant for analysis and downloading
dependencies, not for changing the pom.xml. Maybe the
[tidy-maven-plugin|http://mojo.codehaus.org/tidy-maven-plugin/] is a better
maven-plugin for such an option or a tool like [Forge|http://forge.jboss.org/]
> new mojo to move dependencies up/down within multi-module projects
> ------------------------------------------------------------------
>
> Key: MDEP-218
> URL: https://jira.codehaus.org/browse/MDEP-218
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Reporter: jieryn
> Assignee: Robert Scholte
> 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 was sent by Atlassian JIRA
(v6.1.6#6162)
