Leo Simons wrote:
I suggest we move to strike and loudly proclaim descriptors not living in gump CVS as harmful. Their use needs to be *strongly* discouraged from now on. Who's with me?
I agree with you as a general principle.
Too bad that the entire cocoon build system relies on the gump descriptor for its blocks and this is going to be so for a while.
If you deprecate href, cocoon will be seriously damaged.
Now, I am the one to blame for this,
Actually I was the one that started it ;-P
History: when I needed a descriptor for Centipede, I looked at the Gump one, and extended it. Then Cocoon needed a similar system, so out of my experience with Centipede I created the code-generating block build system....
but my rationale was to keep gump and cocoon in synch by making sure that everytime you built cocoon, you were also testing if the gump descriptor was right.
...that was what I thought...
Of course, only gump can do the full check, but the cocoon build can help a little bit.
... and here is where it broke. The fact is that the two are now so different in the way they work that the check is not good enough.
Or we make the Cocoon build system more akin to Gump, or we make something that keeps the two descriptors lazily in synch.
Stefano, I need your help. We've been banging our head on this for months, and I still remember a discussion like this with Sam more than a year ago. We *must* resolve this.
Let's see:
1. Gump needs to have all the descriptors at hand. Href is too volatile for Gump.
2. Gumpers need to be able to change that information.
3. Project developers need to be able to change that info too.
4. The two descriptors should be able to stey out of synch.
So:
From point 1 and 2 we need a repository with all the descriptors.
From point 3 and 4 we need to have a replication system between the repository and the project.
Let's say that each project has a Gump descriptor in the Gump repo and *can* *also* have an href. A cron job can check the two and report the differrences to the respective communities (ie the one that has the oldest descriptor). In this way we have bi-community peer review of changes.
Even better, on every descriptor checkin, a quick build is performed with last night's jars, to see that the descriptor works. But this is part of the -build per checkin- thing that is on the agenda in any case.
So, is this an option. Let's get this nailed :-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
