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