[
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114300
]
Venelin Mitov commented on MSITE-129:
-------------------------------------
I would be also very interested in having this issue fixed.
In the organization where I work we use a model quite similar to the one
explained by Mark. Our POM hierarchy contains 3 levels:
1. superpom - contains basic configuration inherited by all projects, for
example <reporting>, <dependencyManagement>;
2. project types - contains configuration for specific project types (i.e.
common configuration for the maven-eclipse, -ejb, -jar, -war and -ear -
plugins); Currently we support the following maven projects: JAR, WAR, EJB and
EAR;
3. Individual projects that inherit from one of the project types;
We use maven pom inheritance to express those hierarchical relationships. This
way we minimize the effort to configure the individual project poms. On the
other side we use maven-modules to manage the application sub-system
organization.
So Matt, I am glad to realize that our solutions are pritty similar, while
developed in different organizations, and I beleive this is a quite natural way
to take advantage of the Maven 2 Project OBJECT ORIENTED Model.
Is it really so tricky to fix this from implementation point of view?
John, what exactly do you mean by
"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" ( ! )"
Having a look in the Maven-Model specification
(http://maven.apache.org/ref/2.0.4/maven-model/maven.html):
modules - The modules (sometimes called subprojects) to build as a part of
this project. Each module listed is a relative path to the directory containing
the module.
Wouldn't the maven multimodule build fail if for some reason it cannot find a
project's module - otherwise it cannot create the reactor?
Best regards,
Venelin
> 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: 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
