My negatives for Alexandria:
* Seems large and yet dead * Has lofty goals, whereas the below is very basic
Gump is another possibility. I noticed the other day that they have javadoc in the gump.xml.
My argument for the below over trying to do things with gump is that it is simple to get running and find out what we actually want. Once we have that, we can try to drive gump/alexandria/something-else.
Hen
On Fri, 18 Mar 2005, Jeff Martin wrote:
Just wondering if anyone had looked at Alexandria. http://jakarta.apache.org/alexandria/legacy/
On Fri, 2005-03-18 at 00:31 -0500, Henri Yandell wrote:
On Thu, 17 Mar 2005, J Aaron Farr wrote:
On Wed, 16 Mar 2005 00:49:08 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> wrote:
Interested in finding out if anyone else thinks this would be a good idea.
Rather than have each subproject managing their release javadocs separately, I think it would be good if we treated the javadoc more like the releases. Located in a central location, perhaps mirrored, all versions available and perhaps with additional tools like ashkelon or multidoc to bring them together.
I guess I'm hoping for something like:
http://api.apache.org/$group/$artifact/$version/
Sounds good, though possibly:
http://jakarta.apache.org/api/$subproject/$artifact/$version/
to get a prototype up and running.
with features like
* download the javadocs
+1. Unsure how this would balance with the download pages.
* search javadocs
+1 long-term.
* have javadocs linked to source reference (so maybe have an 'api' and a 'src' directory)
Not hugely essential I think.
* have javadocs linked to each other
Would be very nice, but seems like a battle. We wouldn't want to rebuild the javadoc as part of this, and might not be easy to find a way to munge existing javadoc to point to each other. Also means dependency knowledge, which version of Collections did this BeanUtils use.
* include test and taglib javadocs
+1 on taglibs. Test ones are less essential to start with I think.
Plus it's got to be pretty simple to set this up or for projects to contribute to it.
To start with, I'm generally thinking of a defined file structure in which unzipped javadocs appear, a location for downloadable javadoc to be and a front end to make it easy to get to the relevant javadoc.
A release would involve putting the new javadoc in place, adding it to the front-end (hopefully in a one-line kind of way) and then creating a downloadable zip.
Initial plan would be to propose a structure for the repository (I like yours), go extract a lot of javadocs from our downloads to seed the repository, and come up with a simple-front-end to let people use them.
An important requirement will be the need for a subproject/group to be able to link to a page that defines their javadoc, rather than at the top level.
Hen
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]-- Jeff Martin
Memetic Engineer
http://www.custommonkey.org/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
