You are viewing a plain text version of this content. The canonical link for it is here.
Posted to alexandria-dev@jakarta.apache.org by josh lucas <lu...@collab.net> on 2001/08/29 07:53:01 UTC

Thoughts on the future

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.

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.

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.



josh

---------------------------------------------------------------------
To unsubscribe, e-mail: alexandria-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org


Re: Thoughts on the future

Posted by "Kevin A. Burton" <bu...@openprivacy.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

josh lucas <lu...@collab.net> writes:
<snip>

> There used to be an example on Kevin Burton's site, relativity.yi.org
> but I'm not sure if it is still there. Putting up a demo might be useful
> though.

That demo was VERY old.  In fact it was only running on a PII 400 an it was
buckling under the stress.  :(

It was still funny how many page hits it got :(

Kevin

- -- 
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org )
        Cell: 415-595-9965 URL: http://relativity.yi.org ICQ: 73488596 

Learn from other people's mistakes, you don't have time to make your own.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt

iD8DBQE7jXu8AwM6xb2dfE0RApTeAJ4jm1Gi4y0Yl66Gu9veSerZNf1SkwCgqYOy
sSilMehCbXV2X+RdyKQQim0=
=Af7e
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: alexandria-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org


Re: Thoughts on the future

Posted by josh lucas <lu...@collab.net>.
On Wed, 2001-08-29 at 05:01, Jesse McConnell wrote:
> One thought I mentioned awhile ago on this list was that I would like to 
> have the ability to monitor multiple builds, say on different platforms 
> with different versions of the jdk.  Similar to the way tinderbox from 
> mozilla is used.  I have the mozilla toolchain here I work, but I would 
> like to move to a better system then a bunch of perl scripts.  Don't get 
> me wrong, I love perl...prolley my best language, but I am interested in 
> what can be done with Alexandria in terms of a native java system.

I think this would be very cool and would probably be the result of
extending Gump/AntGump/Maven to handle this.

> 
> Seems like a lot of people are using junit for a lot of the testing 
> needs, so that can be better integrated into the whole of alexandria. 
> But I digress, a central server type system that receives the build 
> information from various sources would be a big selling feature for me. 
>   I don't know how others feel on that.
> 
> Josh, I applaude your efforts to revitalize this project and eagerly 
> await a list of tasks that I may contribute to.
> 
> Jesse
> 
> P.S. I would think that getting the demo of what currently exists 
> working on the main apache page would be pretty important...I for one 
> have not even seen this thing working.  Could be what I mention above 
> exists.. :)
> 

There used to be an example on Kevin Burton's site, relativity.yi.org
but I'm not sure if it is still there. Putting up a demo might be useful
though.


josh

---------------------------------------------------------------------
To unsubscribe, e-mail: alexandria-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org


Re: Thoughts on the future

Posted by Jesse McConnell <je...@gallup.com>.
One thought I mentioned awhile ago on this list was that I would like to 
have the ability to monitor multiple builds, say on different platforms 
with different versions of the jdk.  Similar to the way tinderbox from 
mozilla is used.  I have the mozilla toolchain here I work, but I would 
like to move to a better system then a bunch of perl scripts.  Don't get 
me wrong, I love perl...prolley my best language, but I am interested in 
what can be done with Alexandria in terms of a native java system.

Seems like a lot of people are using junit for a lot of the testing 
needs, so that can be better integrated into the whole of alexandria. 
But I digress, a central server type system that receives the build 
information from various sources would be a big selling feature for me. 
  I don't know how others feel on that.

Josh, I applaude your efforts to revitalize this project and eagerly 
await a list of tasks that I may contribute to.

Jesse

P.S. I would think that getting the demo of what currently exists 
working on the main apache page would be pretty important...I for one 
have not even seen this thing working.  Could be what I mention above 
exists.. :)

josh lucas 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.
> 
> 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.
> 
> 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.
> 
> 
> 
> josh
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: alexandria-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: alexandria-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org


Re: Thoughts on the future

Posted by Jason van Zyl <jv...@apache.org>.
On 8/29/01 1:53 AM, "josh lucas" <lu...@collab.net> 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: alexandria-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org

-- 

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: alexandria-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: alexandria-dev-help@jakarta.apache.org