cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [2.2] Dynamic xconf try to open non-existing files (bug?)
Date Sun, 13 Feb 2005 15:58:56 GMT
Daniel Fagerstrom wrote:

> I would prefer generating gump.xml from block.xml. It will be easier to
> develop and deploy (external) blocks if all info about them is contained
> within the block. Also it is better to have a block.xml format that not
> is dependent on gump's format as it allow us to put all info that we
> want to have about blocks in that file.
> IIRC we went for the gump solution as we where concerned about the lack
> of robustness in generating the gump.xml on demand. Also the gump format
> was close enough for our needs back then. But now I think that the
> centralized gump.xml is in the way for a smooth evolution towards "real"
> blocks. The robustness issue can maybe be handled in other ways, e.g.
> compile time checks of the block.xml, so that no one happens to check in
> a faulty block.xml that kills the compilation.
> Thinking further about it: could not the blocks be own Gump sub projects
> that depends on Cocoon core? If that is possible it would only be
> necessary to have a list of the blocks that we want to have checked by
> Gump, no need for a centralized list containing all block dependencies.
I think we should really start and move all blocks out of the core
(for 2.2 - 2.1.x should stay as is) and then it would make sense for me 
to have
an own gump descriptor for each block.

I also agree that it's better to generate the gump descriptor from the 
block descriptor than vice versa. If we go this road, there is only one 
issue to solve: how does Cocoon know which blocks are available? Just 
scanning the src/blocks directory isn't enough. Blocks can be anywhere 
in the file system. The current build system is able to include blocks 
from any location.


Carsten Ziegeler - Open Source Group, S&N AG

View raw message