[ http://jira.codehaus.org/browse/MSITE-129?page=comments#action_65330 ]
John Allen commented on MSITE-129: ---------------------------------- IMHO this all comes about from the approach of only providing access to the model hierarchy (i.e. fully interpolated and evaluated parent and child project hierarchy) via the reactor and the fact that a <parent> referred POM doesn't have to refer to its children via <modules>. (note that the project.getParent() is broken too - you dont get an evaluated model back, another reason we try and use the reactor for model accessing). It is a strange relationship to have containment relationships that are different from the inheritance relationship in this kind of setup. Any hardened Makefile builder knows that things can get very strange if you do too much of that. Inclusion techniques are a much better way to go when trying to achieve these kind of space saver/convience hacks. What are project modules? Are they children? Are they a 'type of' relationship? Currently not (as in your case) but i bet 99% of people will assume they are and align their parent and module relationships that way. I think this is the killer point, if in a OOAD space you have a means of doing something that most people would not think of as possible in OOAS it's probably not a good thing to allow them to do it. I do see the benefits of this technique (well kind of) but i would have thought you could maintain a true parent-child relqationship and not have non-parent projects acting as collector projects for modules not in their ancestory. The only reason to refer to the reactor in all this is to work around failings in the maven model runtime that does not allow you to access module resources via the project.getModules(). For this reason the two schemes of module accessing (one via the reactor and the other via a direct filesystem read and build) are used and it is the inconsistency between this inheritance and containment scheme that you've introduced (or leveraged) that really shows these issues in their true, nasty light. In my simple take on OO (spanning 15 years) I think one should be able to access the full object hierarchy without running in the reactor. That would allow module state to be accessed during -N builds. I also think <module> means child and therefore the child and parent should be related. I struggled greatly with this aspect of the maven design/implementation when i first came to m2 and despite understanding where it derives from I still feel it is an an indication of someting not being quite right. Should a project be buildable in isolation of its parent? No, it needs its inherited state and will source it either from the filesystem or the repository. Should a project be able to build in isolation of its modules? Yes/No, Yes for *its* generated artefacts (scope and responsibilities and all that) but then No when the site plugin tries to access its child project's state... Just my $0.02... > 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
