My involvement was with what has now become tucked away in a zip file called alexandria-legacy. At this time Alexandria was an ant build script with some ant extensions. Most of these are now part of ant.
Alexandra's main goal was to allow people to access javadoc and xrefed source code. The build and testing stuff was just a logical extension of having a system which could automatically checkout code. Gump now handles this much better. Anyway just trying to bring people's attention to an existing solution rather than trying to start everything from scratch. On Fri, 2005-03-18 at 12:22 -0500, Henri Yandell wrote: > 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] -- jeff martin information technologist mkodo limited mobile: 44 (0) 78 55 478 331 phone: 44 (0) 20 77 29 45 45 email: [EMAIL PROTECTED] www.mkodo.com 73 Leonard St, London, EC2A 4QS. U.K --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
