- 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 interest.
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:
http://cvs.apache.org/viewcvs/jakarta-gump/project/Attic/xml-cocoon2.xml
- Sam Ruby
