[JIRA] Commented: (CC-202) generate configxml.html automatically
"Dan Rollo (JIRA)" <[email protected]>
| Newsgroups | gmane.comp.java.cruise-control.devel |
|---|---|
| Message-ID | <1683056291.1288048669917.JavaMail.jira@chidmzhosting02.thoughtworks.com> |
[ http://jira.public.thoughtworks.org/browse/CC-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_18829 ]
Dan Rollo commented on CC-202:
------------------------------
Seth,
I'm OK with leaving the @DescriptionFile .html files in the source tree, so long as most plugins don't require one.
Re: Docs of Doc Best Practices - Whatever you prefer. If you do put them in http://cruisecontrol.sourceforge.net/main/plugins.html#xmldocumentation, you should add a note about how the generated file is actually named ...-gendoc.html in dir.... This way, anyone who reads and follows the docs will not feel they've been mislead.
I'd guess the best way to get community help on doc'ing the plugins is to document the "best practices"/annotations (as we're discussing), and then also have an examples. If even one plugin per month got converted docs, it wouldn't take long to do them all. A few examples that are completed (using best and non-best practices) would be nice.
JMX tests = good.
I think you are mind melding with Jerome. ;) He started the gendoc work, and IIRC, he also did much of the work on the Plugin classes, so I am not surprised if there's opportunity for reuse/refactoring there. Submitting Jira tickets is a good way to track such things, though you might want to post to the dev mailing list first.
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: Dan Rollo
> 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-v2.4.diff, patch-v2.5.diff, patch-v2.6.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
------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev