Since these questions have come from time to time on the mailing list without good answers, I'll write down some experiences from the field. First, for the parent links (when browsing a child module in a multimodule project), the only way I've been able to make them appear is I have to have a site.xml, specifying <menu ref="parent"/>. Since you need to have a site.xml for any other little customization anyway, it's not too big of a deal.
The site plugin doesn't have proper support for deploying versioned sites to separate destinations. This is often useful and desired in a corporate/business environment where you officially support multiple versions of your software. One of the issues is that the url element doesn't work correctly with properties (http://jira.codehaus.org/browse/MNG-3244). The other issue is that the site distribution url has to be unique for each version. The site plugin doesn't have support for it but it's fairly easy to do with something like scp://myhost.com/varwww/myproject/versions/${ project.version}. In my current case, we also needed a snapshot of the current trunk to be published to the same fixed url. This is considerably harder with properties alone, but solvable with profiles because a profile can contain a distributionManagement element. In this case, our standard pom contains the snapshot url and publishing to a release site is done by activating a specific profile. Site plugin replaces absolute urls with relative ones where ever possible, so the site generally works ok except some information, like the url in project summary report is wrong (but acceptable for us, as it points to the latest snapshot). Replacing absolute urls with relative ones is also pretty annyoing in some cases ( http://jira.codehaus.org/browse/MSITE-159), like when you refer to static resources (like images) from the site.xml of your parent, but the links won't work anymore in the child modules. If we need an absolute url, we typically use an alias or even an ip for the same host to circumvent the problem. We refer to the release versioned sites from the index page of the main site (that is using apt format) and then do some trickery to replace the index pages with release notes for the versioned sites during the site build with antrun plugin, activated by the same profile for versioned distributionManagement. We specify project and site distribution url only in the parent pom, and use version 2.0-beta-6 of the site plugin and pretty much the latest of all other plugins. There are many variations to how people might want to set up the sites which could make things much harder, but the above is relatively simple to set up and we can live with the quirks. Still, it's a far cry of the usability of a site that combines both aspects of a wiki and a static Maven site, like the one I set up for Trails project (http://trailsframework.org/). It seemlessly integrates Maven info & reports into a Confluence-based site with the help of heavily customized Maven-site skin and Codehaus' Confluenza, a utility that's responsible for creating the layout and pulling the data from wiki via xmlrpc. Too bad it's only possible to do this in specific environments... a maven-xwikisite-plugin would be nice, anyone up for a challenge? ;) Kalle
