[JIRA] Commented: (CC-202) generate configxml.html automatically

    [ http://jira.public.thoughtworks.org/browse/CC-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_18790 ] 

Dan Rollo commented on CC-202:
------------------------------

Hi Seth,

Welcome back! Sorry your break has ended. ;) 

If you run the "release.bat/sh" in the project root, you'll end up with a "website" folder in the target directory off the project root - IIRC.
When we release a new version, the content of that dir is published as the website (eg: the website NOT dynamically read from subversion).

You might have the ant target generate your new "configxml.html" with a new name, but put it in the same dir as the current "configxml.html", eg:
documentation/main/configxml-gendoc.html

That should make it easier to discover any issues between the old configxml.html and the new configxml-gendoc.html (with the idea being that eventually we will remove configxml.html from version control and use the file built by gendoc instead. Clear as mud?

Dan

> generate configxml.html automatically
> -------------------------------------
>
>                 Key: CC-202
>                 URL: http://jira.public.thoughtworks.org/browse/CC-202
>             Project: CruiseControl
>          Issue Type: Improvement
>          Components: Documentation
>    Affects Versions: 2.2.1
>            Reporter: Jerome Lacoste
>         Assigned To: Jeffrey Fredrick
>            Priority: Trivial
>         Attachments: CC-202-part2-v1.diff, configxml.html, configxml.html, configxml.html, configxml.html, Gendoc Design Proposal v2.0.pdf, net.sourceforge.cruisecontrol.ProjectConfig.xml, patch-v2.0.diff, patch-v2.1.diff, patch-v2.2.diff, patch-v2.3.diff, patch-v6-part1.diff, patch-v6-part2.diff, patch_before_cleanup_and_full_conversion.diff, patch_v3.diff, patch_v4.diff, patch_v5.diff, proof-of-concept-diff.log, proof-of-concept-diff.txt, proof-of-concept-diff.txt
>
>
> Several people have expressed their desire of having such feature.
> xdoclet sounds like a good candidate for this problem. If addressed that way, this issue can be broken down in several steps:
> - identify the documentation requirements
> - create a tag specification that would allow to solve these requirements. 
>   We might lose some features as we will perhaps not be able to be as flexible as with the manual documentation
> - write the xdoclet tags that help to generate the intermediate XML
> - create an XSL template that generates the HTML from the intermediate XML
> - move the current configxml.html into tags inside the code
> - update the build/release process to generate the documentation

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.public.thoughtworks.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev