[
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
