Jon Stevens wrote:
>
> Is it cool if I import my generic nightly export/binary system into
> Alexandria? It seems like this project would be the best place for it.
Would it be possible to drive your scripts off of a common set of data
definitions with any of the current alexandria code bases? The current
alexandria proposals ("classic", "gump", and "ant") speak different
dialects of the same basic language, but we are slowly converging. What I
see in your projects directory is in quite a different direction entirely.
I must confess that I was just about to make a proposal that we split the
data definitions out into a separate cvs. Something like a
jakarta-alexandria-data. Now I wish I had made that proposal first ;-) In
any case, the set of people who should have commit access to the project
definitions is arguably different (and in general, larger) than the set of
people who can be trusted to make changes to the implementation itself.
Also, I have been slowly making progress in getting projects to accept
nightly builds using the latest of everything is a useful thing to have. I
already have jakarta-ant, jakarta-avalon-*, jakarta-slide, jakarta-regexp,
xml-xalan, xml-soap, and xml-axis signed up - these nightlies are all
produced by Gump. It is all part of my diabolical plan to get people
addicted to Gump to the point where the actually care if the builds fail.
;-)
However, I am quite willing to say that the above is simply a "use case",
and a generic build system should be able to be adapted to multiple
purposes. But I would still like to see if there is some way that we can
get all of the various proposals under the jakarta-alexandria umbrella to
at least be driven off of the same data definitions.
What I envision in a jakarta-avalon-data is a series of "profiles".
Perhaps one designed to build a system using stable versions of each of the
components, another which picks up milestone/beta versions, and one
designed to pick up the absolute latest. In such a future, while little or
none of the original code in the Gump proposal may live on in its present
form, what will remain is a profile.
So, how about it? It there any hope of adopting a common set of project
definitions, independent of the "engine" that drives the process?
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
