Sam Ruby wrote:
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).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.
OTOH, if a project descriptor were to actually replace an ant build file, I really doubt the descriptor would still rot as badly.
Which is a thoughtline we could extend to levelling out cvs privs across the ASF but that's a different argumen t;)What's worse is that people who care are excluded from making changes.
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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
