Sam Ruby wrote:
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. :-PNicola Ken Barozzi wrote: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...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.
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.
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.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?2) Gump has a profile, Centipede just looks at the descriptor in the project dir.
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.
So...
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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
