[jira] Closed: (MNG-3066) Allow the specification of modules with project coordinates

["Jason van Zyl (JIRA)" <ji...@codehaus.org>]

     [ http://jira.codehaus.org/browse/MNG-3066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason van Zyl closed MNG-3066.
------------------------------

    Resolution: Won't Fix

Modules are defined as being in scope at the file system level. We're not looking for modules in repositories.

> Allow the specification of modules with project coordinates
> -----------------------------------------------------------
>
>                 Key: MNG-3066
>                 URL: http://jira.codehaus.org/browse/MNG-3066
>             Project: Maven 2
>          Issue Type: New Feature
>    Affects Versions: 2.0.6
>            Reporter: Steven Cummings
>             Fix For: 3.x
>
>
> Currently, modules can only be specified by the parent POM as "simple paths", i.e., relative to the current project, like "module-a" and "../module-a". This explicit filesystem relation between parent project and modules can cause issues like CONTINUUM-1163.
> It makes sense to allow modules to be specified with project coordinates, like:
> <module>
>   <artifactId>module-a</artifactId>
>   <groupId>com.mygroup</groupId>
> </module>
> This way no explicit filesystem or SCM relation has to exist. The only requirement would be that the parent project is able to locate the specified artifact in one of its defined repositories (or repositories from settings.xml), and the artifact's POM contain an SCM section so that it can check out the code.
> From there, maven can decide what temporary space to check out and build the "child" project in, perhaps .m2-workspace or .m2-modules-temp in the user-home. Perhaps this also could be configured in settings.xml just like the local repository location.
> The value of this would be:
> * Parent projects no longer have to exist "one level above" or relative to all of its modules in SCM and the checkout filesystem.
> * When SCM is organized such that not all of the module projects are in the same folder, project coordinates could be simpler than relative paths.
> * When not all of the projects are in the same SCM repos, then the current module scheme won't even work.
> * It would be nice to have the ability to create ad-hoc parent POMs just for the purpose of executing arbitrary group builds. The modules can't specify more than one parent, but there may be more than one grouping from the top-down perspective.
> ** A good example is where a team has several groupIds that all of their projects are grouped into. Perhaps they don't want use parent POMs, or each group has unique configuration and so each has a different parent POM for its projects to inherit. Then, the group wants to run a global dashboard (dashboard-maven-plugin) report on all projects in all groups but not really use this new parent POM for inheritance or settings, only for the aggregation. They'd like this so that there is one place to go to observe the health of the team's projects.
> * Finally, some operating systems (to remained un-named because this is their defect...) have path limits of around 255 characters. Sometimes forcing modules to exist under or relative to their parent causes the checkouts for the group to surpass this limit. If there are projects already close to this limit, the path of the parent project can push paths of package directories and long class-names on over that limit.

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