Stefano Mazzocchi wrote:
> > 1) Refactor the project-info.xml to split in several files contained > > in the blocks themselves. > Just like Eclipse plugin.xml files in their plugins, a plugin is > installed by just dropping it in the plugins dir. Usecase: This will > make it easy for me to maintain my JavadocSource block (or any > (external) block for that matter), now I need to sync each time when > project-info.xml changes ;-)
This is called for, I totally agree. I was going to tackle that problem today, anybody against this?
is anything using that project-info.xml file or is just a left-over from the old build system?
The build mechanism uses it to generate the build file; but I guess you know this
yes :)
- 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.
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?)
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.
Suggestions?
-- Stefano Mazzocchi <[EMAIL PROTECTED]> Pluralitas non est ponenda sine necessitate [William of Ockham] --------------------------------------------------------------------
