Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
I think this is not too hard to do: a simple ant task that copies the xconf for a block into the xconf directory and adds all include statements.
The more it think about this, the more I believe that <imports> should not be done explicitly but implicitly, based on some aggregated dependency information (for example, the blocks should have their block descriptor block.xml and include the dependency information there)
If I have time, I will look into that this weekend, but can't promise anything :)
The include features in xconf allows to very simply add or remove a block by just moving files around. I would like to keep this simplicity and avoid by all means to go back to some build-time generation of these files like we have today with xpatch in 2.1
Amen.
There aren't that much inter-block dependencies, and I don't have the feeling hand maintaining them is really complicated.
What I would like to see is something like this:
1) src/block/*/block.xml
that contains something as simple as
<block name="a"> <depends-on block="b"/> <depends-on block="c"/> </block>
2) this info used by cocoon at startup time (NOT COMPILE TIME!) to drive the xconf imports.
How hard can that be!?!
Mmmh... maybe not that much, but this requires a naming and/or lookup scheme for these files. We could enumerate all files having the same name ClassLoader.getResources() but I suspect we'll be encountering some problems related to classloader hierarchies. Or we can include it from a block's xconf using "resource://" as we already do it for roles.
Several points come to mind also:
1) we are defining a strong contract for the location and names of block xconf files, namely "context://WEB-INF/xconf/cocoon-${block}.xconf" whereas today they can be placed anywhere because they are explicitely included. I have nothing against this, but this contract must be well stated and defined as we will live with it for a long time.
2) how is this related to gump.xml, which already contains inter-block dependency information? Can gump.xml be generated from the various block.xml files or does Gump require it to be a static resource? I personally would prefer gump.xml to be generated from the various blocks as the dependency information belongs to the block rather than to a centralized resource.
3) we've seen that some inter-block dependencies only come from the samples. That means we must be able to distinguish real block dependencies from the additional dependencies brought by samples.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
