cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <>
Subject Re: [New build system] Status of samples
Date Fri, 28 Feb 2003 14:45:06 GMT
Stefano Mazzocchi wrote:
>> - apart from that, I don't think so. Isn't this a gump descriptor?
> I just made it became so. Previously it was just a copy and the real 
> descriptor was in the jakarta-gump repository. Now, Gump picks it up 
> from here so this means we have to keep it updated.

My two cents: what you just did was significantly reduce the number of 
people who can keep this updated.  My experience in the past has been 
that this always is a bad thing, but perhaps Cocoon will prove me wrong.

>> For me it looks totally confusing anyway.
> I totally agree, even if the choice of separating blocks into their own 
> gump projects makes it easier to obtain a clean cocoon run in Gump by 
> lowering the dependency needs for the core (Sam, did we ever get a clean 
> Cocoon2 gump build?)

We have gotten close, but we have never to my knowledge gotten a clean 
gump build of cocoon.

>> So I'm +1 on removing it and
>> replacing it with per block-versions that use a better XML syntax.
>> For pluggable blocks we need this anyway.
> Yes, completely.
> Sam, is it possible to have Gump obtain a dynamically generated project 
> descriptor? what would allow us to keep our block descriptors as we like 
> and generate a gump descriptor dynamically.
> Yes, I know that it doesn't change that often and that we could file it 
> into the jakarta-gump repository at need, but I'm sure that people will 
> forget to do it, or, even worse, update it by hand.

There are a number of answers to this question, each of them fairly 
lengthy.  I'll give short answers and will expand on each if there is 

First, my feeling is that if there is a better syntax, I would like to 
simply adopt it.  I don't care what the definition of better is: 
technical, community, whatever.

Second, I care very deeply that the process is bootstrapable.  I don't 
want the dynamic generation of a descriptor to depend on the building of 
a generator which is described by a descriptor which is generated 
dynamically by that generator...

> Suggestions?

Let's jointly work to improve the syntax and ensure that the descriptors 
can still be updated by the people who have been maintaining it to date:

- Sam Ruby

View raw message