Leo Simons wrote:
Berin Loritsch wrote:
I noticed that within the JavaDocs there are some testcases (like
metagenerate). To reduce the bulk of the site we should exclude
the test cases from the JavaDoc build process. I am not sure
exactly how the amalgamated JavaDoc is done, but I am sure we can
exclude stuff like that.
there's an ant buildfile in jakarta-avalons-site. Run
ant javadocs
ant jdoconly
to generate the docs. I stripped testcases for everything but framework,
phoenix & logkit. I figured it be good to keep some testcases in
because, well, one should know we do have testcases. (BTW I seperated
the targets out because it keeps the JVM within memory constraints.)
I agree that people should know we have testcases, but I would prefer
to publish the reports generated by <junitreport> for that case. That
not only lets people know that we have testcases, but that the currently
released product has passed those testcases.
Is there anything else we can think of to exclude from the JavaDocs
on the web? Should we limit the JavaDocs to only released products?
My thinking is that javadocs for released products should be part of the
release, and that bleeding-edge javadocs should go on the website.
Whether javadocs for released products should also go on the
website....don't have a strong opinion. It's a pain to manage with CVS.
That's true. Is there anyway we can automatically generate JavaDocs in
a weekly batch process on the server? That way we don't have to worry
about it at all in the CVS.
Although, the truth is that I would prefer bleeding edge stuff to not
be released on the web site because it is changing often, and it adds
extra management that we can't really keep up with.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
