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]