Berin Loritsch wrote:
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.
good point. Added "remove testcases and put up junitreport" to my TODO :D
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?
yes :D My plan is to either get gump to do this for us, or to set up a
crontab on an asf machine, or set up a crontab on a non-asf machine.
Still need to figure out which one :D
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.
"automate everything" :D We'll get there.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
