maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte (JIRA)" <j...@codehaus.org>
Subject [jira] (MDEP-218) new mojo to move dependencies up/down within multi-module projects
Date Thu, 07 Aug 2014 19:10:10 GMT

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

Mime
View raw message