RE: development status
"Stou Sandalski" <[email protected]> Mon, 7 Jul 2003 22:22:40 -0700
| Newsgroups | gmane.comp.jakarta.alexandria.devel |
|---|---|
| Message-ID | <000801c34510$f3ea7cd0$6701a8c0@muon> |
Haha I usually get told what features an app has and all I have to do is code it... I am not really sure how to write a doc listing the features... all I can think of at the moment (because its basically all I have needed)... is an application that can: - Browse the source code repository in real time (not a checked out version), different revisions, tags, log entries... show the file contents with syntax highlighting (like enscript does for viewcvs) - Allow users to download tarballs of different revisions and modules (anonymous cvs straight from the site basically)... - Show a graphical representation of the revision tree. - Generate javadocs, and docs for other languages too. - Cross linking of code so it can be browsed easier not just flat style but with links to different functions... (kind of like xlr does it) - It would be nice to be able to link straight to a line of code or function from the outside (so bug tracking systems can link straight to) - should possibly provide access control on a per-project basis (one installation multiple projects) That's kind of it, basically I was thinking of something that's xlr+viewcvs+cvsgraph+javadoc all wrapped up into one, easily customizable and expandable, built on top of existing frameworks (apache has so many projects I really can't keep up)... I was thinking that stuff that requires a lot of text processing (lxr, and docs) can be cached (database, files, whatever)... and will only have to be done against tags in the CVS not every file revision (maybe?)... I am not sure how much of this fits in... but yea, sorry for the novelette. : ) Stou > -----Original Message----- > From: news [mailto:[email protected]] On Behalf Of Nicola Ken Barozzi > Sent: Monday, July 07, 2003 1:31 AM > To: [email protected] > Subject: Re: development status <snip> > Well, the goal of Alexandria is to generate documentation about a > project. ATM it is made to work to generate the docs offline, and here > is an example: > http://cvs.apache.org/~nicolaken/whiteboard/alexandria-docs/xml-cocoon/ > > But this is not optimal it seems, as the size of the generated docs is > very big, and I doubt that generating all this stuff statically for big > projects is going to be the answer. > So yes, I'm very interested in seeing it go to a server-based solution, > with the possibility of still generating the offline docs for who wanbts > them. > > There is an Apache project called Cocoon http://cocoon.apache.org/ that > can be very nice for this, as it also powers Forrest > http://xml.apache.org/forrest/, so that Alexandria and Forrest could > integrate visually and in linking. > > What I would propose you to do now, is to hash out a document that > describes the functionality that you0d like to see in this server-based > version of Alexandria, and see how the current static functionality can > be accounted for. > > Thanks :-) > > -- > Nicola Ken Barozzi [email protected] > - verba volant, scripta manent - > (discussions get forgotten, just code remains) > --------------------------------------------------------------------- > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected]