[jira] Issue Comment Edited: (MSITE-129) modules list empty if modules don't use this project as parent in reactor build

["John Allen (JIRA)" <ji...@codehaus.org>]

    [ http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103004 ] 

John Allen edited comment on MSITE-129 at 7/23/07 12:30 PM:
------------------------------------------------------------

I'm curious should a site be displaying a project's modules or a project's children (i.e. 'inherited from' projects)? I know I am more interested in the later when I'm browsing sub-systems, as, as with any design effort, one divides and conquers, layering common behaviour and semantics as you decompose. But I would then expect those children to be part of this natural aggregated scope - if something is a child then it is an ordered  relationship with its parent and it should be possible to view/navigate/build following those relationships in both directions.

It's worth noting that the dual behaviour re how to find parents/modules comes from the attempt to support generating a site for a project that has modules and or a parent but is not running in the reactor. If one says that modules are not children but simply an aggregation, and thus parent's can not know of their children in a declarative way, then the only way to deduce children of a project is to have a reactor and to re-build the inheritance hierarchy from the the edges up, thus discovering the true project ancestry.

Without a declarative way for a parent to specify its children then the parent site will never be able to list its children without a reactor and inferencing. Maybe we should add a new semantic to help us here that differentiates from a project's children (inheritance) and modules (collection)? 


 was:
I'm curious should a site be displaying a project's modules or a project's children (i.e. 'inherited from' projects)? I know I am more interested in the later when I'm browsing sub-systems, as, as with any design effort, one divides and conquers, layering common behaviour and semantics as you decompose. But I would then expect those children to be part of this natural aggregated scope - if something is a child then it is an ordered  relationship with its parent and it should be possible to view/navigate/build following those relationships in both directions.

It's worth noting that the dual behaviour re how to find parents/modules comes the attempt to support generating a site for a project that has modules and or a parent but is not running in the reactor. If one says that modules are not children but simply an aggregation, and thus parent's can not know of their children in a declarative way, then the only way to deduce children of a project is to have a reactor and to re-build the inheritance hierarchy from the the edges up, thus discovering the true project ancestry.

Without a declarative way for a parent to specify its children then the parent site will never be able to list its children without a reactor and inferencing. Maybe we should add a new semantic to help us here that differentiates from a project's children (inheritance) and modules (collection)? 

> modules list empty if modules don't use this project as parent in reactor build
> -------------------------------------------------------------------------------
>
>                 Key: MSITE-129
>                 URL: http://jira.codehaus.org/browse/MSITE-129
>             Project: Maven 2.x Site Plugin
>          Issue Type: Bug
>    Affects Versions: 2.0-beta-5
>            Reporter: Kenney Westerhof
>            Assignee: Kenney Westerhof
>            Priority: Minor
>             Fix For: 2.0-beta-7
>
>
> The code in the AbstractSiteRenderingMojo does the following:
> - if it's running in a reactor build (i.e. more than 1 project in the reactor projects) it scans all
> projects to see if it's parent project equals the current project. If so, it's marked as a module.
> - if it's running on a single project, the project.build.modules is consulted and those modules
> are marked as modules.
> I've got a 'fake' root pom, for utility purposes: it lists all projects as modules so that I can easily
> built everything and generate a site. However, this fake root pom is never used as a parent - there's
> a /pom/pom.xml project for that.
> The result of this is that the modules list is empty.
> A workaround is to first run 'mvn site' and then 'mvn site -N'.
> I'm not sure what the correct solution should be - basically now 2 site layouts are implemented:
> - a physical layout where the modules match the <modules> section of the pom, reflecting filesystem layout,
> - a project hierarchy layout based on <parent>
> and one or the other is used depending on wheter the build contains more than 1 project or not.
> My first feeling is that since the tag is called ${modules} (or <menu ref="modules"/>) that
> the site should use the <modules>, not the <parent>. 
> It should also take into consideration, that IF a reactor build is running, it should only use the modules that are also
> in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a site with not all projects in it).
> Thoughts?

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