[ http://jira.codehaus.org/browse/MSITE-129?page=comments#action_65334 ]
Kenney Westerhof commented on MSITE-129: ---------------------------------------- Hi John, You're quite right. In effect, there are 2 trees, which usually overlap: the parent->child(module) tree, and the child->parent tree. The result is that if you see them both as 1 structure you get a graph, not a tree. At first I wasn't sure of your concern, since I just want a set of links from any project referring to its children. You wouldn't need to access the child at all, you only need to know it's name in order to create correct links. But this goes wrong as soon as the <module> name does not match the module's artifactId, so I now understand why the reactor is consulted to find the same relation but in the other direction. This suffers from the same problem - a parent-(module)->child relation does not imply a child-(parent)->parent relation. There's really no way to find a child project just by scanning the modules.. So, how to proceed? A working solution would be to still keep the two types of relationships separate, but specify the groupId/artifactId instead of just a module name. Another would be to just see the modules definition as a build-time instruction (in which case it really should be in the <build> section), and the only official relationship would be the <parent> declaration in children. The reason I have a parent for easy building is that my repository is split up in much the same way as the Maven repository: for each top level project I have a directory containing trunk/branch/tags, and I have a trunks/ with svn:externals properties to */trunk/. The trunks/ also contains a pom but that's only used for building all projects. The real parent pom is also versioned in a top level project. It might be simplest to add the limitation that if you declare a module in project A, then that module MUST declare a <parent> for module A. On the other hand - the checked-out versions don't have to match at all; project A can be version 1.1, the child declaring a parent relation with version 1.0. Seems like we stumbled on a large shortcoming in the design: you can define a structure that's completely legal in M2 terms, but when some assumptions (children declare the correct parent, and module names equal artifactId) are not met, strange problems present themselves. It seems some unsaid 'best practises' are not implemented the same everywhere - the site plugin being an excellent example of this, since it employs two entirely different strategies depending on the number of projects in the reactor. > 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 > Type: Bug > Versions: 2.0-beta-5 > Reporter: Kenney Westerhof > Assignee: Kenney Westerhof > 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
