gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: cvs commit: jakarta-gump/project jakarta-ant.xml jakarta-commons.xml jakarta-taglibs.xml uddi4j.xml xml-crimson.xml xml-xerces.xml
Date Sun, 05 Jan 2003 16:30:46 GMT

Sam Ruby wrote:
> Nicola Ken Barozzi wrote:
>> Sam Ruby wrote:
>>> Nicola Ken Barozzi wrote:
>>>> Centipede projects use the descriptor to run normal builds, so they 
>>>> will not move.
>>> Gump can follow hrefs, why can't centipede?
>> 1) I don't want my machine to be connnected to the internet
>>    just to build my project. Gump downloads every run so it's not
>>    an issue.
> What could be better than to have a single place which you can check out 
> all descriptors?  Imagine all the cross project information you could 
> generate offline...

What could be better than have the descriptor in synch and close to the 
actual codebase? Don't just assume that Gump is the center of the 
universe.  :-P

Ok, getting real, what you say and what I say are IMHO both notable 
features that fill real needs. Needs are never in discord, 
implamantations are. Let's see how we can fix implementations to make 
all needs satisfied.

>> 2) Gump has a profile, Centipede just looks at the descriptor
>>    in the project dir.
> Perhaps Centipede could have an option / profile / properties file that 
> indicates where you have a locally checked out jakarta-gump/project 
> directory, and will look in there if the descriptor is not found locally?

Yes, it's not a bad idea. I had started doing it but it was too early, 
we needed to do other things first. We are now working on a Gump 
integration that would make Centipede spit out a correct profile to 
build local projects and use Gump for that.

But I do still strongly think that a descriptor of a project should 
remain with the project. Or you want me to put all buildfiles in Gump 
too? ;-P

Ok, getting real again: think about a Centipede user that wants to build 
a project. Hmmm, let me try and see it from a Gump perspective. It 
downloads Gump, and Gump has the descriptor. Then it tells Gump to 
download the project from CVS. Ok, so far it's cool. Then it builds it 
and Centipede looks in Gump to find the descriptor. Cool again.

Ok, I like this. But let's see the drawbacks:

  - the project descriptor is not with the project itself. It's in 
another dir. Imagine the buildfile be in another dir... hmmm, not nice IMHO.

  - a project is on SF and needs to change the descriptor. They need to 
ask Gump committers to do it. Your vision is ok till we talk about 
Apache projects, but is not so nice (it seems) for others.

  - Some projects don't want to Gump, so their descriptors are local in 
the project dir, not Gump's. So we have some projects with the decriptor 
near, some in Gump. Hmmm...

It seems we need some kind of synching here...

Suppose Gump keeps the descriptors. It's mandated by the fact that we 
use Gump to bootstrap other projects by downloading them.

But then, I want the descriptor with the project. So the developers can 
use them *near* the code, and change them as needed.


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?

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message