Sites and Inheritence

MavneMaven's support for sites that span multiple projects has generally been limited to date. The following are some features that will assist in this.

...

<menu name="Commons Common">
  <item ... />
</menu>

<menu name="Commons Specifics" inherit="bottom">
  <item ... />
</menu>

Including Generated Content

Currently there are elements like ${reports} and ${modules} in the site descriptor. These will be deprecated in favour of:

  <!-- Include all info and reports -->
  <menu ref="reports" />

  <menu ref="modules" />

~~TODO: not happy with this yet

Symmetric generation

When generating within the top level, content will be generated into the target/site location of the subproject, using the difference between the top level URL and the subproject's URL as the relative path to use. It will not be possible to navigate between the sites on the filesystem - you must push to staging to achieve this.

...

The location of site.xml relative to a project is determined by plugin configuration as normal, and defaults to src/site. When locating a parent project, this is done using the normal workspaces/USD technique (using relativePath in the POM, falling back to the repository. Parent project documents are not needed - only the site descriptor.

Report aggregation

Most of the work of this is covered in the individual plugins and the Maven Dashboard discussion, and is out of scope for this document. While the site mojo itself will not be an @aggregator, individual reports are free to do so and should behave correctly.

Breadcrumbing

Breadcrumbs will be stored in the <breadcrumbs /> element.

...

By default, the name element of the project will be used as the breadcrumb.

Report aggregation

Most of the work of this is covered in the individual plugins and the Maven Dashboard discussion. When running the site from the top level, it behaves as an @aggregator so that it is repsonsible for generating all of the child projects, rather than using the reactor to do so. This will enable final aggregation.

Skinning

Skinning support will provided by a separate artifact that contains CSS, images and is unpakced unpacked over a site. It can optionally contain a replacement /META-INF/maven/site.vm velocity template for generating the final XHTML.

It is built as a normal JAR, using a custom packaging of "maven-skin". To configure the skin in the client, add it to the site plugindescriptor:

<plugin>
  <artifactId>maven-site-plugin</artifactId><project>
...
  <configuration>
    <skinArtifact><skin>
      <groupId>org.apache.maven.maven<skins</groupId>
      <artifactId>maven-sitedefault-skin</artifactId>
      <version>1.0-SNAPSHOT<0</version>
 <!--   </skinArtifact>optional -->
  </configuration>

Separation of user and developer documentation

...

skin>
...

Separation of different releases in documentation

see http://jira.codehaus.org/browse/MNG-41^{Image Removed}