> Cool. And we should look at pulling in content for jSieve, too. What is > your plan?
Its weak at the moment but I've just pulled together a solution to a similar problem internally at work, how to get multiple different product version document sets and a largely independant set of general docs integrated into a simple process. Work's solution uses Maven, I'm trying to figure out how I can translate this to an ant build. What we do as part of the release process is simply to generate the product documentation and publish it into a directory named with the version label, the "site" is also xdocs and exists as another project with mainly just the "general" xdocs in it, therefore you can edit and version the site content without troubling the product docs, and publish product docs during releases without having to become concerned with the main site. We'll need to think about how we deal with multiple doc sets in terms of profligate use of disk space, perhaps we limit ourselves to publishing "stable". But by separating docs from src and bin downloads we make every older version's docs available as a straightforward download->unzip Not sure exactly where this'll end up yet, but thats my current thinking on process. I also wondered about using xdoclet to make nice mailet & matcher docs from javadocs, or of using a templated format. I don't think its an issue yet, but it may be if we follow the obvious path of moving "provided" M&M's out of James and let them exhibit their own lifecycles. At which point we'll need to version and aggregate their documentation too. d.
