[
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103404
]
John Allen commented on MSITE-129:
----------------------------------
Kenney, how can we go about dealing with these two cases?
* A user wishes to have all the modules appear.
Okay so I guess with the tag being called <ref=modules> then this is what it
was originally intended to do and the reactor based code should be changed to
only find the modules from the reactor, not the inheriting projects (as it does
at the moment).
The benefits to using the reactor is that it's quick and the projects are fully
interpolated. If there's no reactor we try and build the models from the
fileystem module POMs. I'm not sure how interpolated they are, ie if the module
has ${} values in it are they evaluated? (didnt used to be the case but could
be now). If there are no filesystem modules available then it's a pure nasty
hack of setting the module project's name and url to be the value found in the
root project's <modules><module> element, which for flat multimodule type
scenarios will be "../somename" ( ! )
* A user wishes to have the children appear in the site, regardless of the
modules.
This is what users like me want. I guess a configuration option could be used
to distinguish this behaviour rather than a new site.xml element. Either way
this is easy for the reactor based 'child project's find but for the mvn -N
situations one would need to create all the module projects from their file
system pom.xml files and then check if their parent clauses match the current
project.
Actually that doesn't sound to be bad to me. Thoughts?
> 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
