It will be some mildly tedious work to move the current doc to xdocs, but nothing too bad, and if they are valid xhtml, it will be much easier.
The documentation is all XML now. Steve was just tweaking the XLS. There's a bit of HTML/XHTML in the sample applications, but that's trivial and probably wouldn't be a Maven issue anyway.
I'm no expert, but I'll be happy to help where I can. It can be a little frustrating to push an existing CVS structure into Maven conventions (I tried to do it for SnipSnap and really got stuck, but their build is pretty funky.) It's a breeze when you start fresh (like maybe Struts 2.0...)
So it sounds like that since Maven is also a build tool, we not only have to address the web site/documentation content but bring CVS in line.
Unless someone is of the opinion that moving the Struts CVS to Maven conventions is a no-brainer, perhaps the consensus should be to consider Maven for any *new* Struts product installations (CVS/website combinations). This could include
+ A new CVS/website for the taglibs + A new CVS/website for Struts 2.x (which is now just a roadmap)
So, given either or both of these, the Struts home page could become a simple portal that links to our products (1.x core, taglibs, 2.x roadmap).
Once we got started on Maven using "fresh meat", we could then make a informed decision about whether to migrate the Struts 1.x core.
Meanwhile (assuming the 1.x CVS is an issue), if someone were interested in moving the 1.x documentation to Forrest, I wouldn't be opposed.
-Ted.
(Just a random thought, would either Maven or Forrest care that how we generate the taglib API documentation from the TLDs?)
-- Ted Husted, Junit in Action - <http://www.manning.com/massol/>, Struts in Action - <http://husted.com/struts/book.html>, JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
