Yesterday I've been trying various ways to create the torque4 site similar to our current site. Currently (in 3.3), we have the following: - we have a core site in the site project and the module sites (e.g. for the runtime) in the modules - the site looks like one because we play various navigation tricks in the modules (e.g. import the core navigation from outside)
This has the following advantages: - The site is easily navigable, the module structure is not transferred to the site - each module still gets its reports (e.g. javadoc, checkstyle...) automatically generated to the site. It has the problem that the navigation hack is not easily understandeable, and does not work on non-deployed sites. Now,using maven2, the navigation hack does not work anymore because - one cannot generate the reports in a subdirectory, it has to be a root menu. - the importing via xml entities does not work anymore. The "fixed" xdoc module documentation would not be problematic, it is not that important where they are in svn as long as there's a defined place. It's the dynamic reports that cause the trouble because they have the fixed position in navigation in the maven2 build. So now there are some alternatives: 1) use the standard maven multiproject site layout. This uses a different site for each module, with links in the main module back and forth. I do not like this because it has a bad usability. As an example, look at e.g. http://tapestry.apache.org/tapestry4.1/index.html and how it links to each module, e.g. tapestry core (http://tapestry.apache.org/tapestry4.1/tapestry-framework/index.html). Compare this how seamlessly the modules in the current Torque site integrate into the main site (http://db.apache.org/torque/releases/torque-3.3/runtime/index.html and http://db.apache.org/torque/) 2) bad hacking. Use XSLT to parse out the report body from the module reports, and use copy&filter to insert the reports in dummy documents in the main site. This might be fragile, and is not a standard method. 3) Do not publish reports of the modules on the main site. But having the javadoc, checkstyle report, pmd report etc on the site is very nice in my opinion. 4) Use something completely else to build the site. But I do not know any alternatives which also generate similar reports. I'm unsure what to do. 2) might work, but needs some prototyping. Perhaps, 1) is not as catastrophal from the users experience so we might opt for this. Staying with the maven1 build is not an option in my opinion. I'd be grateful for any good ideas or recommendations. Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
