[jira] (MDEP-218) new mojo to move dependencies up/down within multi-module projects

["Robert Scholte (JIRA)" <ji...@codehaus.org>]

     [ 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)