[
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165319#action_165319
]
John Allen edited comment on MSITE-129 at 2/12/09 12:00 PM:
------------------------------------------------------------
Module locations (and thus links) are based upon project.distro.site.url and
project.url. They have no bearing on where a module is on the filesystem.
The structure you have drawn as 'what it should be' is stating that the
submodules inherit from myproj, which they dont. And thats why in the generated
site they dont live under it.
There are two very different namespaces here and none of them are related.
One is the filesystem. In this case your myproj and its sub dirs. This
namespace has no bearing on the URL namespace or for that matter the project
inheritance relationships.
The next is the project hierarchy. That does have a relationship to the URL
namespace, only IF, you inherit the settings for project.url and
project.distributionManagement.site.url. However if you override those at each
project level then these two are unrelated.
When a project deploys itself into the URL space, it uses its distro.site.url
to work out where it should go. This obviously needs to be related to the
project's URL otherwise it will deploy to a location that no other project will
ever be able to find by using that project's URL.
The module projects all do the same, namely deploy to locations dependent upon
their distro.site.url.
So first up, there is no relationship between the deployemnt URL location and
the filesystem structure.
A aggregator project, such as myproj generates links to its modules. These its
calculates by asking each module, what is your DEPLOYED project url. Each
project returns its URL and the aggregator project calculates the relative
paths (if possible) to the module projects from its own URL.
You did deploy the projects to check that the module links were woerking didnt
you? They will never work in an undeployed state.
was (Author: skaze):
df
> 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
> Components: multi module
> Affects Versions: 2.0-beta-5
> Reporter: Kenney Westerhof
> Assignee: Dennis Lundberg
> Priority: Minor
> Fix For: 2.0
>
>
> 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
