db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <fisc...@seitenbau.net>
Subject torque 4: maven2 site hell
Date Fri, 12 Feb 2010 09:33:49 GMT

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: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org


Mime
View raw message