On Fri, 18 Mar 2005, J Aaron Farr wrote:
On Fri, 18 Mar 2005 12:22:35 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote:
Gump is another possibility. I noticed the other day that they have javadoc in the gump.xml.
Trouble with having this Gump driven is that Gump is all about building the latest snapshot, not about building a specific release version. Moreover, the builds have a pretty high failure rate.
Right.
But that does bring up a good question about where the javadocs come from. Would this site/tool generate them directly from the source or would projects have to supply the javadocs? If projects have to supply the pre-generated Javadocs then we could just require they are distributed via the mirrors and this site could pick them up from there.
First I was thinking that it would be this way. We'd effectively get a working prototype of how things can look and user's can find javadocs a lot more easily, without us having to try and guess what a more complex system would look like.
The only pain created would be as an addition to release management, which is annoying as release management is already a slow enough process, but we're going to be tying this to releases no matter what happens anyway.
However, if the site generates the javadocs then we'd have a lot more control over how they look and how they're linked.
Then I would see us discussing this. It could involve loading into ashkelon etc. We'd have a basic working system to use as a foundation to all the ideas.
Hen
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
