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 Leo Simons <le...@apache.org> on 2003/01/05 22:09:39 UTC
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Sam Ruby wrote:
> Nicola Ken Barozzi wrote:
>> What about making Gump commit the latest descriptors in its CVS at
>> every run? With the possibility of not-synching for some projects in
>> case ASF developers want to try and fix the Gump version?
>
> Let express my root need or requirement, then we can discuss
> implementations.
>
> My experience is that if descriptors are moved to Avalon, they rot.
yup. Also, I like having the descriptors that gump uses locally as it
makes 'ant gen' run faster, and one can do checking of edits without
having to commit (as it is now, I have to commit the project descriptor
in avalon in order to test it does as it should using gump).
OTOH, if a project descriptor were to actually replace an ant build
file, I really doubt the descriptor would still rot as badly.
> What's worse is that people who care are excluded from making changes.
Which is a thoughtline we could extend to levelling out cvs privs across
the ASF but that's a different argumen t;)
long thought process below (nothing better to do)...
----
I like Seperation of Concerns:
concern 1: building of a software project. You want a way to
automatically build software releases and related materials (website 'n
stuff)
concern 2: testing of a software project. I usually want to do this at
least every hour or so when I'm working on stuff. Avalon has very little
in the way of unittests but for projects at work I often run 'ant test'
using watch, re-running as much as every 5 mins or so.
concern 3: dependency verification for a set of related software
projects. You want to make sure a change in product X doesn't affect
product Y.
concern 4: providing "early access" downloads of development version of
a software project.
(did I get all of em?)
how do these concerns relate?
Well, the first step in testing a project is usually making sure it
builds, ie there's real close coupling between 1 & 2.
The coupling between (1+2) on the one hand and 3 on the other is more
loose: it can be acceptable for a project to work with version y of a
project and then not with version z because of backwards-incompatible
changes, as long as this is a design decision.
The coupling between 4 and 1 is again big: an early acess download
basically is an easily accessible build of the project.
---
The value of ant is that it provides a scripting language for handling
of tasks 1 & 2 (another benefit is that scripting languages are easily
'abused' for other tasks).
The value of gump is that it handles task 3. In doing so, it basically
defers responsibility for task 1 & 2 (which need to be accomplished in
order to do 3) back to ant.
The output of gump automatically results in early access downloads if a
gump run succeeds.
---
The annoying bit is that it is not possible to simply put the data that
gump needs in a form as simple as:
asfRepo="cvs.apache.org:/home/cvspublic";
sfRepo="cvs.sf.net:/home/cvspublic";
...
asfModules="$asfRepo:jakarta-ant $asfRepo:jakarta-avalon
$asfRepo:jakarta-tomcat ...";
...
modules="$asfModules $sfModules ...";
doyourmagicon $modules;
because not every project uses ant, every project that does uses it
slightly differently, it is not so easy to override something defined in
an ant buildfile, and it is not so easy to figure out relationships
between ant buildfiles. Hence the data that must be fed into gump is a
lot more elaborate.
---
So, what's the plan? We replace ant's buildfile by something from which
ant's buildfile is generated (heck, actual use of ant can become
optional!), *and* from which gumps descriptors are also generated. In
fact, it might be possible to generate the ant buildfile by adding just
a little bit of info into the gump descriptor. Tada: centipede!
---
You already knew all this. Now a concern in a different dimension: who
takes care of the various tasks, and how does this fit in with the
technology we use (cvs), and the access control required?
The people that develop the software want to be able to modify their
build script as they modify their software; otherwise testing becomes
problematic.
The people that develop the software apparantly don't care too much for
maintaining the dependency mapping, so you want the people that _do_
care about that to be able to maintain the dependency mappings for them.
When you merge the dependency mapping and the build scripts into a
single file, there's an access priviledge issue: two different groups of
people need access.
---
I see two main options:
1) give the people that develop the software access to the project that
maintains the descriptors (ie give all developers access to gump); give
the people that administer the dependencies access too.
2) give the people that administer the dependencies access to all
software projects.
neither is really satisfactory: giving "all developers" access to gump
would mean wiki-style access control which people are afraid of, whereas
giving the gump admins access to all software is going to affect the
'personal playground feeling and/or software security' of the software
projects.
For apache, the choice is rather easy to make: we generally trust all
asf committers to behave, and hence opening up the gump repo should not
present a problem. With the modest size of the new repo, it is also not
a big burden to keep a local copy of the gump repo updated. Once you
adjust to the idea "the project descriptor is in a different cvs",
there's virtually no difference.
Taking into account the rest of the world is more difficult. However,
for gump in its current form, keeping in sync with "the rest of the
world" appears to be manageable by the gump admins.
---
which leads me to believe that the current setup is the best -- we do both:
Put the ASF project descriptors in the gump repo, and put the non-ASF
project descriptors elsewhere, where those projects have the option to
give the dependency magicians (like sam) access to their project descriptor.
---
To solve the centipede problem @ apache: simply make the gump repo a
requirment for building the project! That might also help 'edjucate'
ignorant developers (like, until recently, me) about the wonders and
importance of gump.
If I have to do
cvs co jakarta-avalon jakarta-gump
centipede jakarta-gump/projects/jakarta-avalon.xml
instead of
cvs co jakarta-avalon
centipede jakarta-avalon/project-descriptor.xml
well, I can live with that. And if I can have the commands
cvs co jakarta-avalon
ant jakarta-avalon/build.xml
result in the same thing, what's left to complain about? :D
g'night!
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote:
> Nicola Ken Barozzi wrote:
>
>> I was thinking about the conceptual idea of having
>> descriptors for Centipede projects in Gump CVS, and how this would
>> make things difficult for Centipede projects.
>
> Suggestion: let's just note that it is very easy to move descriptors.
>
> For ASF projects which are not (yet) centipede based, the path of least
> resistance seems to be to put them in the gump cvs repository.
>
> Given the current implementation of Centipede, the path of least
> resistance for projects which are currently and actively using centipede
> is to put such project descriptors in the project cvs.
>
> Moving project descriptors in anticipation of future use seems
> counter-productive at this time.
>
> Future versions of gump or centipede (or centigump or gumpipede or
> whatever) may change these observations.
[...]
> Peace?
:-)
I agree on all the line. Well said. Thank you.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote:
> Nicola Ken Barozzi wrote:
>
>> I was thinking about the conceptual idea of having
>> descriptors for Centipede projects in Gump CVS, and how this would
>> make things difficult for Centipede projects.
>
> Suggestion: let's just note that it is very easy to move descriptors.
>
> For ASF projects which are not (yet) centipede based, the path of least
> resistance seems to be to put them in the gump cvs repository.
>
> Given the current implementation of Centipede, the path of least
> resistance for projects which are currently and actively using centipede
> is to put such project descriptors in the project cvs.
>
> Moving project descriptors in anticipation of future use seems
> counter-productive at this time.
>
> Future versions of gump or centipede (or centigump or gumpipede or
> whatever) may change these observations.
[...]
> Peace?
:-)
I agree on all the line. Well said. Thank you.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Sam Ruby <ru...@apache.org>.
Nicola Ken Barozzi wrote:
>
>> well, no (and it's not to be taken as a proposal ;). But it is the
>> easiest thing that could possibly work (in that I could probably set
>> it up). I'm totally supportive for real solutions, but I'm okay with
>> hacky solutions until those real solutions arrive (to paraphrase Berin
>> "waiting until the next release of [the maven and centipede] projects").
>
> Yes, I agree too. I was thinking about the conceptual idea of having
> descriptors for Centipede projects in Gump CVS, and how this would make
> things difficult for Centipede projects.
Suggestion: let's just note that it is very easy to move descriptors.
For ASF projects which are not (yet) centipede based, the path of least
resistance seems to be to put them in the gump cvs repository.
Given the current implementation of Centipede, the path of least
resistance for projects which are currently and actively using centipede
is to put such project descriptors in the project cvs.
Moving project descriptors in anticipation of future use seems
counter-productive at this time.
Future versions of gump or centipede (or centigump or gumpipede or
whatever) may change these observations.
Finally, despite these observations, people are free to put their
descriptors in any accessible location as long as they are willing to
actively maintain them.
Peace?
- Sam Ruby
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Sam Ruby <ru...@apache.org>.
Nicola Ken Barozzi wrote:
>
>> well, no (and it's not to be taken as a proposal ;). But it is the
>> easiest thing that could possibly work (in that I could probably set
>> it up). I'm totally supportive for real solutions, but I'm okay with
>> hacky solutions until those real solutions arrive (to paraphrase Berin
>> "waiting until the next release of [the maven and centipede] projects").
>
> Yes, I agree too. I was thinking about the conceptual idea of having
> descriptors for Centipede projects in Gump CVS, and how this would make
> things difficult for Centipede projects.
Suggestion: let's just note that it is very easy to move descriptors.
For ASF projects which are not (yet) centipede based, the path of least
resistance seems to be to put them in the gump cvs repository.
Given the current implementation of Centipede, the path of least
resistance for projects which are currently and actively using centipede
is to put such project descriptors in the project cvs.
Moving project descriptors in anticipation of future use seems
counter-productive at this time.
Future versions of gump or centipede (or centigump or gumpipede or
whatever) may change these observations.
Finally, despite these observations, people are free to put their
descriptors in any accessible location as long as they are willing to
actively maintain them.
Peace?
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> Nicola Ken Barozzi wrote:
>
>>> To solve the centipede problem @ apache: simply make the gump repo a
>>> requirment for building the project! That might also help 'edjucate'
>>> ignorant developers (like, until recently, me) about the wonders and
>>> importance of gump.
>>
[...]
>> Doesn't it also have to work?
>
>
> Nicola, I'm really not trying to make your life harder, or make your job
> on centipede more difficult. Really. But fact-of-the-matter, right now,
> and for the past few months, the avalon peeps (including you and me)
> have been terrible at maintaining gump descriptors (or even the build
> process), and until I see things work differently (I've been trying) I'm
> thinking along the same lines Sam is.
For Avalon, as for any *Ant* project, now that Gump is open to all
Apache, I agree. I have in fact moved now the descriptor back in Gump CVS.
My point is about *Centipede* projects. POI now builds fine with Gump,
and it uses Centipede.
If Centipede makes it compulsory to have a descriptor just to do normal
builds, I reckon that putting the descriptor in Gump CVS is not needed,
and even, as I'm trying to suggest, a problem.
[...]
>> Honestly, Leo, imagine you're a Centipede developer. And you want to
>> give an easy build system to your users. Do you really think that your
>> proposal is a real solution?
>
>
> well, no (and it's not to be taken as a proposal ;). But it is the
> easiest thing that could possibly work (in that I could probably set it
> up). I'm totally supportive for real solutions, but I'm okay with hacky
> solutions until those real solutions arrive (to paraphrase Berin
> "waiting until the next release of [the maven and centipede] projects").
Yes, I agree too. I was thinking about the conceptual idea of having
descriptors for Centipede projects in Gump CVS, and how this would make
things difficult for Centipede projects.
>> Look at it from my perspective too.
>
> I am, I am!
:-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> Nicola Ken Barozzi wrote:
>
>>> To solve the centipede problem @ apache: simply make the gump repo a
>>> requirment for building the project! That might also help 'edjucate'
>>> ignorant developers (like, until recently, me) about the wonders and
>>> importance of gump.
>>
[...]
>> Doesn't it also have to work?
>
>
> Nicola, I'm really not trying to make your life harder, or make your job
> on centipede more difficult. Really. But fact-of-the-matter, right now,
> and for the past few months, the avalon peeps (including you and me)
> have been terrible at maintaining gump descriptors (or even the build
> process), and until I see things work differently (I've been trying) I'm
> thinking along the same lines Sam is.
For Avalon, as for any *Ant* project, now that Gump is open to all
Apache, I agree. I have in fact moved now the descriptor back in Gump CVS.
My point is about *Centipede* projects. POI now builds fine with Gump,
and it uses Centipede.
If Centipede makes it compulsory to have a descriptor just to do normal
builds, I reckon that putting the descriptor in Gump CVS is not needed,
and even, as I'm trying to suggest, a problem.
[...]
>> Honestly, Leo, imagine you're a Centipede developer. And you want to
>> give an easy build system to your users. Do you really think that your
>> proposal is a real solution?
>
>
> well, no (and it's not to be taken as a proposal ;). But it is the
> easiest thing that could possibly work (in that I could probably set it
> up). I'm totally supportive for real solutions, but I'm okay with hacky
> solutions until those real solutions arrive (to paraphrase Berin
> "waiting until the next release of [the maven and centipede] projects").
Yes, I agree too. I was thinking about the conceptual idea of having
descriptors for Centipede projects in Gump CVS, and how this would make
things difficult for Centipede projects.
>> Look at it from my perspective too.
>
> I am, I am!
:-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Leo Simons <le...@apache.org>.
Nicola Ken Barozzi wrote:
>> To solve the centipede problem @ apache: simply make the gump repo a
>> requirment for building the project! That might also help 'edjucate'
>> ignorant developers (like, until recently, me) about the wonders and
>> importance of gump.
>
> Checking out the Gump repo will help ignorant developers understand the
> wonders and importance of Gump?
well, yeah. You need to be aggressively slamming 'em on the head with
it, and then putting it within their line of sight. I had a filter on
'[GUMP]', sending the messages to a special folder marked 'need-to-fix'
and with a red font. Didn't actually work. Verbally hit me on the head
with something and I'll work on it though (thanks Sam :).
> Doesn't it also have to work?
Nicola, I'm really not trying to make your life harder, or make your job
on centipede more difficult. Really. But fact-of-the-matter, right now,
and for the past few months, the avalon peeps (including you and me)
have been terrible at maintaining gump descriptors (or even the build
process), and until I see things work differently (I've been trying) I'm
thinking along the same lines Sam is.
> Make it easy to use and I can start to
> agree. That's what we want to do by making a system that automatically
> creates a profile for your local Gump, given the local projects.
sounds good to me. More work, better results :D
I'm just being a real pragmatist: I need a fortress release (that's one
of the packages in avalon-excalibur that doesn't work) in a few weeks,
and I'd like a few nightly builds to start testing.
>> If I have to do
>>
>> cvs co jakarta-avalon jakarta-gump
>> centipede jakarta-gump/projects/jakarta-avalon.xml
>>
>> instead of
>>
>> cvs co jakarta-avalon
>> centipede jakarta-avalon/project-descriptor.xml
>>
>> well, I can live with that.
>
> So a user that gets a source distro of a project, he cannot compile
> without also downloading Gump?
IIUC, something that could work right now is copying the gump descriptor
into the base dir of the source distro, and putting in place a different
'.properties' file or something like that?
>> And if I can have the commands
>>
>> cvs co jakarta-avalon
>> ant jakarta-avalon/build.xml
>>
>> result in the same thing, what's left to complain about? :D
btw, my idea was that build.xml would check out gump and centipede,
acting as a 'bootstrap'. Should be doable, no? ie something like:
<project default="main">
<target name="main">
<cvs checkout="${centipede}" repo="${krysalis}"
dir=".."/>
<cvs checkout="${gump}" repo="${jakarta}"
dir=".."/>
<exec script="../${centipede}/bootstrap.sh"/>
<cent/>
<gump/>
</target>
</project>
> Honestly, Leo, imagine you're a Centipede developer. And you want to
> give an easy build system to your users. Do you really think that your
> proposal is a real solution?
well, no (and it's not to be taken as a proposal ;). But it is the
easiest thing that could possibly work (in that I could probably set it
up). I'm totally supportive for real solutions, but I'm okay with hacky
solutions until those real solutions arrive (to paraphrase Berin
"waiting until the next release of [the maven and centipede] projects").
> Look at it from my perspective too.
I am, I am!
cheers,
- Leo
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Leo Simons <le...@apache.org>.
Nicola Ken Barozzi wrote:
>> To solve the centipede problem @ apache: simply make the gump repo a
>> requirment for building the project! That might also help 'edjucate'
>> ignorant developers (like, until recently, me) about the wonders and
>> importance of gump.
>
> Checking out the Gump repo will help ignorant developers understand the
> wonders and importance of Gump?
well, yeah. You need to be aggressively slamming 'em on the head with
it, and then putting it within their line of sight. I had a filter on
'[GUMP]', sending the messages to a special folder marked 'need-to-fix'
and with a red font. Didn't actually work. Verbally hit me on the head
with something and I'll work on it though (thanks Sam :).
> Doesn't it also have to work?
Nicola, I'm really not trying to make your life harder, or make your job
on centipede more difficult. Really. But fact-of-the-matter, right now,
and for the past few months, the avalon peeps (including you and me)
have been terrible at maintaining gump descriptors (or even the build
process), and until I see things work differently (I've been trying) I'm
thinking along the same lines Sam is.
> Make it easy to use and I can start to
> agree. That's what we want to do by making a system that automatically
> creates a profile for your local Gump, given the local projects.
sounds good to me. More work, better results :D
I'm just being a real pragmatist: I need a fortress release (that's one
of the packages in avalon-excalibur that doesn't work) in a few weeks,
and I'd like a few nightly builds to start testing.
>> If I have to do
>>
>> cvs co jakarta-avalon jakarta-gump
>> centipede jakarta-gump/projects/jakarta-avalon.xml
>>
>> instead of
>>
>> cvs co jakarta-avalon
>> centipede jakarta-avalon/project-descriptor.xml
>>
>> well, I can live with that.
>
> So a user that gets a source distro of a project, he cannot compile
> without also downloading Gump?
IIUC, something that could work right now is copying the gump descriptor
into the base dir of the source distro, and putting in place a different
'.properties' file or something like that?
>> And if I can have the commands
>>
>> cvs co jakarta-avalon
>> ant jakarta-avalon/build.xml
>>
>> result in the same thing, what's left to complain about? :D
btw, my idea was that build.xml would check out gump and centipede,
acting as a 'bootstrap'. Should be doable, no? ie something like:
<project default="main">
<target name="main">
<cvs checkout="${centipede}" repo="${krysalis}"
dir=".."/>
<cvs checkout="${gump}" repo="${jakarta}"
dir=".."/>
<exec script="../${centipede}/bootstrap.sh"/>
<cent/>
<gump/>
</target>
</project>
> Honestly, Leo, imagine you're a Centipede developer. And you want to
> give an easy build system to your users. Do you really think that your
> proposal is a real solution?
well, no (and it's not to be taken as a proposal ;). But it is the
easiest thing that could possibly work (in that I could probably set it
up). I'm totally supportive for real solutions, but I'm okay with hacky
solutions until those real solutions arrive (to paraphrase Berin
"waiting until the next release of [the maven and centipede] projects").
> Look at it from my perspective too.
I am, I am!
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> Sam Ruby wrote:
>
>> Nicola Ken Barozzi wrote:
>>
>>> What about making Gump commit the latest descriptors in its CVS at
>>> every run? With the possibility of not-synching for some projects in
>>> case ASF developers want to try and fix the Gump version?
[...]
> For apache, the choice is rather easy to make: we generally trust all
> asf committers to behave, and hence opening up the gump repo should not
> present a problem. With the modest size of the new repo, it is also not
> a big burden to keep a local copy of the gump repo updated. Once you
> adjust to the idea "the project descriptor is in a different cvs",
> there's virtually no difference.
[...]
>
> which leads me to believe that the current setup is the best -- we do both:
>
> Put the ASF project descriptors in the gump repo, and put the non-ASF
> project descriptors elsewhere, where those projects have the option to
> give the dependency magicians (like sam) access to their project
> descriptor.
>
> ---
>
> To solve the centipede problem @ apache: simply make the gump repo a
> requirment for building the project! That might also help 'edjucate'
> ignorant developers (like, until recently, me) about the wonders and
> importance of gump.
Checking out the Gump repo will help ignorant developers understand the
wonders and importance of Gump?
Doesn't it also have to work? Make it easy to use and I can start to
agree. That's what we want to do by making a system that automatically
creates a profile for your local Gump, given the local projects.
> If I have to do
>
> cvs co jakarta-avalon jakarta-gump
> centipede jakarta-gump/projects/jakarta-avalon.xml
>
> instead of
>
> cvs co jakarta-avalon
> centipede jakarta-avalon/project-descriptor.xml
>
> well, I can live with that.
So a user that gets a source distro of a project, he cannot compile
without also downloading Gump?
> And if I can have the commands
>
> cvs co jakarta-avalon
> ant jakarta-avalon/build.xml
>
> result in the same thing, what's left to complain about? :D
Not with Centipede. With Centipede you *need* the descriptor. That's
what it's all about. If you don't need it to build, it will never be
kept updated.
So I reasonably *need* the descriptor to be with the project. I can
synch with Gump, or viceversa, but in the end I need the descriptor in
the project dir.
Honestly, Leo, imagine you're a Centipede developer. And you want to
give an easy build system to your users. Do you really think that your
proposal is a real solution? Look at it from my perspective too.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> Sam Ruby wrote:
>
>> Nicola Ken Barozzi wrote:
>>
>>> What about making Gump commit the latest descriptors in its CVS at
>>> every run? With the possibility of not-synching for some projects in
>>> case ASF developers want to try and fix the Gump version?
[...]
> For apache, the choice is rather easy to make: we generally trust all
> asf committers to behave, and hence opening up the gump repo should not
> present a problem. With the modest size of the new repo, it is also not
> a big burden to keep a local copy of the gump repo updated. Once you
> adjust to the idea "the project descriptor is in a different cvs",
> there's virtually no difference.
[...]
>
> which leads me to believe that the current setup is the best -- we do both:
>
> Put the ASF project descriptors in the gump repo, and put the non-ASF
> project descriptors elsewhere, where those projects have the option to
> give the dependency magicians (like sam) access to their project
> descriptor.
>
> ---
>
> To solve the centipede problem @ apache: simply make the gump repo a
> requirment for building the project! That might also help 'edjucate'
> ignorant developers (like, until recently, me) about the wonders and
> importance of gump.
Checking out the Gump repo will help ignorant developers understand the
wonders and importance of Gump?
Doesn't it also have to work? Make it easy to use and I can start to
agree. That's what we want to do by making a system that automatically
creates a profile for your local Gump, given the local projects.
> If I have to do
>
> cvs co jakarta-avalon jakarta-gump
> centipede jakarta-gump/projects/jakarta-avalon.xml
>
> instead of
>
> cvs co jakarta-avalon
> centipede jakarta-avalon/project-descriptor.xml
>
> well, I can live with that.
So a user that gets a source distro of a project, he cannot compile
without also downloading Gump?
> And if I can have the commands
>
> cvs co jakarta-avalon
> ant jakarta-avalon/build.xml
>
> result in the same thing, what's left to complain about? :D
Not with Centipede. With Centipede you *need* the descriptor. That's
what it's all about. If you don't need it to build, it will never be
kept updated.
So I reasonably *need* the descriptor to be with the project. I can
synch with Gump, or viceversa, but in the end I need the descriptor in
the project dir.
Honestly, Leo, imagine you're a Centipede developer. And you want to
give an easy build system to your users. Do you really think that your
proposal is a real solution? Look at it from my perspective too.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nick Chalko <ni...@chalko.com>.
Nicola Ken Barozzi wrote:
>
> Sam Ruby wrote:
> [...]
>
>> Suppose centipede had a "gen" step that took a profile or workspace
>> description and produced a single build.xml that could be run
>> completely offline?
>>
>> cvs co jakarta-avalon
>> centipede jakarta-avalon/profile.xml
>> ant jakarta-avalon/build.xml
>>
>> Or, if you prefer, centipede could have options to "gen and run", or
>> "run without regening".
>>
>> Such profiles could even reference multiple projects, and could
>> automatically build each in the correct order.
>>
>> And power users could define workspaces that include multiple
>> profiles, and provide override as appropriate.
>
>
> Welcome to Centipede's view.
>
>
> Actually it would be a bit different.
>
> cvs co jakarta-avalon
> cent
>
> I had at one point included Jenny in Centipede to run gen at every
> project descriptor change, but other things needed to be in place to
> make it run.
>
> So now the goal for me is is:
>
> - centipede builds a single module.
> Dependencies are traversed if the projects are in the same module,
> and centipede builds them in the correct order.
> Outer-module dependencies are automatically downloaded.
> This is a use-case for excalibur.
Lets add another middle goal.
- centipded builds mutliple arbitrary modules.
A user defines a set of modules (a workspace).
centipede all projects, downloading jars for projects not in the
workspace.
This is the use case I need for my clients.
I think supporting this middle ground will cover both ends.
The default workspace is ./module.xml
The max workspace is gump.xml + ./module.xml + others
I think what we con do from centipede is modify gen.sh (probably in
jenny)
Instead of dropping is project when a dependency is not found. add the
depenency as installed package and use ruper(or something) to get the
download the jar.
>
>
> - Centipede shall have a feature that it can automatically install
> a working Gump system with the local Centipede projects.
> The user can then tweak as wanted, and compile every local
> project from local versions using Gump.
> Thus building also non-centipede projects in the process.
>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nick Chalko <ni...@chalko.com>.
Nicola Ken Barozzi wrote:
>
> Sam Ruby wrote:
> [...]
>
>> Suppose centipede had a "gen" step that took a profile or workspace
>> description and produced a single build.xml that could be run
>> completely offline?
>>
>> cvs co jakarta-avalon
>> centipede jakarta-avalon/profile.xml
>> ant jakarta-avalon/build.xml
>>
>> Or, if you prefer, centipede could have options to "gen and run", or
>> "run without regening".
>>
>> Such profiles could even reference multiple projects, and could
>> automatically build each in the correct order.
>>
>> And power users could define workspaces that include multiple
>> profiles, and provide override as appropriate.
>
>
> Welcome to Centipede's view.
>
>
> Actually it would be a bit different.
>
> cvs co jakarta-avalon
> cent
>
> I had at one point included Jenny in Centipede to run gen at every
> project descriptor change, but other things needed to be in place to
> make it run.
>
> So now the goal for me is is:
>
> - centipede builds a single module.
> Dependencies are traversed if the projects are in the same module,
> and centipede builds them in the correct order.
> Outer-module dependencies are automatically downloaded.
> This is a use-case for excalibur.
Lets add another middle goal.
- centipded builds mutliple arbitrary modules.
A user defines a set of modules (a workspace).
centipede all projects, downloading jars for projects not in the
workspace.
This is the use case I need for my clients.
I think supporting this middle ground will cover both ends.
The default workspace is ./module.xml
The max workspace is gump.xml + ./module.xml + others
I think what we con do from centipede is modify gen.sh (probably in
jenny)
Instead of dropping is project when a dependency is not found. add the
depenency as installed package and use ruper(or something) to get the
download the jar.
>
>
> - Centipede shall have a feature that it can automatically install
> a working Gump system with the local Centipede projects.
> The user can then tweak as wanted, and compile every local
> project from local versions using Gump.
> Thus building also non-centipede projects in the process.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote:
[...]
> Suppose centipede had a "gen" step that took a profile or workspace
> description and produced a single build.xml that could be run completely
> offline?
>
> cvs co jakarta-avalon
> centipede jakarta-avalon/profile.xml
> ant jakarta-avalon/build.xml
>
> Or, if you prefer, centipede could have options to "gen and run", or
> "run without regening".
>
> Such profiles could even reference multiple projects, and could
> automatically build each in the correct order.
>
> And power users could define workspaces that include multiple profiles,
> and provide override as appropriate.
Welcome to Centipede's view.
Actually it would be a bit different.
cvs co jakarta-avalon
cent
I had at one point included Jenny in Centipede to run gen at every
project descriptor change, but other things needed to be in place to
make it run.
So now the goal for me is is:
- centipede builds a single module.
Dependencies are traversed if the projects are in the same module,
and centipede builds them in the correct order.
Outer-module dependencies are automatically downloaded.
This is a use-case for excalibur.
- Centipede shall have a feature that it can automatically install
a working Gump system with the local Centipede projects.
The user can then tweak as wanted, and compile every local
project from local versions using Gump.
Thus building also non-centipede projects in the process.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sam Ruby wrote:
[...]
> Suppose centipede had a "gen" step that took a profile or workspace
> description and produced a single build.xml that could be run completely
> offline?
>
> cvs co jakarta-avalon
> centipede jakarta-avalon/profile.xml
> ant jakarta-avalon/build.xml
>
> Or, if you prefer, centipede could have options to "gen and run", or
> "run without regening".
>
> Such profiles could even reference multiple projects, and could
> automatically build each in the correct order.
>
> And power users could define workspaces that include multiple profiles,
> and provide override as appropriate.
Welcome to Centipede's view.
Actually it would be a bit different.
cvs co jakarta-avalon
cent
I had at one point included Jenny in Centipede to run gen at every
project descriptor change, but other things needed to be in place to
make it run.
So now the goal for me is is:
- centipede builds a single module.
Dependencies are traversed if the projects are in the same module,
and centipede builds them in the correct order.
Outer-module dependencies are automatically downloaded.
This is a use-case for excalibur.
- Centipede shall have a feature that it can automatically install
a working Gump system with the local Centipede projects.
The user can then tweak as wanted, and compile every local
project from local versions using Gump.
Thus building also non-centipede projects in the process.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Sam Ruby <ru...@apache.org>.
Leo Simons wrote:
>
> If I have to do
>
> cvs co jakarta-avalon jakarta-gump
> centipede jakarta-gump/projects/jakarta-avalon.xml
>
> instead of
>
> cvs co jakarta-avalon
> centipede jakarta-avalon/project-descriptor.xml
>
> well, I can live with that. And if I can have the commands
>
> cvs co jakarta-avalon
> ant jakarta-avalon/build.xml
>
> result in the same thing, what's left to complain about? :D
You posted is thought provoking. Permit me to respond in kind.
The original intent of the project descriptors was that it be extensible
in multiple directions. Not only that a project descriptor could
contain optional elements that would be ignored by some tools, but that
tools like gump would intelligently "merge" multiple project definitions.
Example: a project definition for jakarta-avalon-db would say that it
simply depends on *a* version of jakarta-regexp. A jakarta-avalon
profile could say that version 1.2 is preferred. The LeoSimons
workspace could say: no, not really, I want to use the version that I
built on my hard drive.
Suppose centipede had a "gen" step that took a profile or workspace
description and produced a single build.xml that could be run completely
offline?
cvs co jakarta-avalon
centipede jakarta-avalon/profile.xml
ant jakarta-avalon/build.xml
Or, if you prefer, centipede could have options to "gen and run", or
"run without regening".
Such profiles could even reference multiple projects, and could
automatically build each in the correct order.
And power users could define workspaces that include multiple profiles,
and provide override as appropriate.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml
jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Posted by Sam Ruby <ru...@apache.org>.
Leo Simons wrote:
>
> If I have to do
>
> cvs co jakarta-avalon jakarta-gump
> centipede jakarta-gump/projects/jakarta-avalon.xml
>
> instead of
>
> cvs co jakarta-avalon
> centipede jakarta-avalon/project-descriptor.xml
>
> well, I can live with that. And if I can have the commands
>
> cvs co jakarta-avalon
> ant jakarta-avalon/build.xml
>
> result in the same thing, what's left to complain about? :D
You posted is thought provoking. Permit me to respond in kind.
The original intent of the project descriptors was that it be extensible
in multiple directions. Not only that a project descriptor could
contain optional elements that would be ignored by some tools, but that
tools like gump would intelligently "merge" multiple project definitions.
Example: a project definition for jakarta-avalon-db would say that it
simply depends on *a* version of jakarta-regexp. A jakarta-avalon
profile could say that version 1.2 is preferred. The LeoSimons
workspace could say: no, not really, I want to use the version that I
built on my hard drive.
Suppose centipede had a "gen" step that took a profile or workspace
description and produced a single build.xml that could be run completely
offline?
cvs co jakarta-avalon
centipede jakarta-avalon/profile.xml
ant jakarta-avalon/build.xml
Or, if you prefer, centipede could have options to "gen and run", or
"run without regening".
Such profiles could even reference multiple projects, and could
automatically build each in the correct order.
And power users could define workspaces that include multiple profiles,
and provide override as appropriate.
- Sam Ruby