On 8/29/01 1:53 AM, "josh lucas" <[EMAIL PROTECTED]> wrote:
> Ok, so one thing which I would really like to do with this mail is to
> generate some discussion about something other than Gump. That isn't to
> say that I don't want to include Gump in the future of Alexandria but I
> want to start with what is currently here and move on from there.
Sounds good.
> I would also like to make it clear that I'm not trying to 'take over'
> the project and steer it somewhere that people don't want it to go. I
> have some ideas which I think would be cool but there is also plenty of
> things in what is currently here to work on. Also, I'd love to hear
> from either Kevin Burton or Jeff Martin as to their thoughts on these
> things. I'm planning on dropping each of them a note to guage their
> thinking.
I agree with Sam in that fresh blood needs to be infused into this project.
Other than the additions of Gump, the new JXR task and Maven I would say
Alexandria is pretty much in a restful coma.
> According to the web site, Alexandria was created to:
>
> create a global documentation and source organization system to help
> people understand source code and to share code across projects.
>
>
> Personally, I think this goal shortchanges Alexandria and limits the use
> by others. I would much rather see Alexandria become a build/test
> system which can be easily integrated into existing projects. There
> would be individual Ant tasks for things like JXR, Changelogs and others
> which would be usable without any additional file creation. The
> task/components could also fit together to create something similar to
> the Gump idea of watching multiple projects.
>
> In order to get to the point where Alexandria has components which can
> be used, a decision has to be made to no longer support the idea of the
> XSD files and Castor. If others support this idea (if not, maybe I'll
> just put it under the proposal directory), here area a few things which
> I'll start with:
>
> 1) Take stock of what is currently here
> 2) Starting with the JXR task, begin to componentize other pieces
> 3) Redocument the new path and the new ideas
> 4) Figure out the best way to move someone from 'old' Alexandria to the
> new thinking
>
> Ok, I think this mail gives the list enough things to discuss. I look
> forward to your feedback.
Here are some ideas in no particular order:
- arrive at a set of dtds/schemas for all the entities we are going to
process. there's a start, but I think they should be documented (which I
volunteer to do) and kept up-to-date.
- tool for building distributions reliably by many people working on a
project. I've been wanting to use gump/maven so that many people working on
turbine can reliably build the tdk as it uses a large number of projects.
- a general java source processing tool. using javacc and one of the
existing grammars, use a variant of pluggable processors that can do
anything with the parsed source. pretty printers, metrics, generators, cross
reference tools, you could make anything really. I see there is a start with
Antlr but it doesn't handle unicode well (it may now, but didn't that last
time I looked at it) and javacc is significantly faster.
- it would be relatively easy to add the javadoc target for a project to the
project dtd and have gump/maven produce the docs.
- a cvsup task that uses CVSup instead of the cvs client, or allow rsync to
get things aligned across machines. possibly even a java implementation of
the rsync algorithm (one might exist). it would good to be able to sync
machines in the fastest way possible.
- I think that the core processing should be independent of ant, though I
made maven an Ant task for convenience to start. It would cool if the whole
lot could be run from the command line or easily integrated into other
applications. I think it would be relatively easy to make ant wrappers
around thing, the ant interface is probably what I would use.
- eventually think about how an individual project can maintain their own
information. if all the project info is going to be stored centrally than a
nice web interface for modifying the project info. Or if the project
descriptor is going to be maintained by each project on their own
servers/machines that how do we deal with that.
- we should definitely use jakarta tools where possible, I think pulling in
the XML descriptors into Java objects is the way to go. Make a set of tools
for processing the descriptors so it's easy for us to do anything with a
project and make a toolkit for others to use if they wish. It would be nice
if the descriptors were uniform with the elements conforming to some
standard so that xml could be mapped to objects strictly using the dtd. a
combination of ant magic with some validation. there's been some talk of
this on the commons list. but I definitely think it's worth having a
standard object model for dealing with project info.
> josh
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
