Marc Portier wrote:
Reinhard Poetz wrote:
Tony Collen wrote:
as said in my previos mail: we *have to* reach a common understanding on what Cocoon *core* is.
it seems logic to me there would be something as 'minimal' and 'typical' as opposed to the current 'full'
More categories would probably be just a waste of energy?
And yeah, I sense somewhat your fear for some long-winding discussion on the outer-boundaries of those (including room for quite some surmising mails eloquently brought as the new testament)...
Now, being really pragmatic, and somewhat inline with Daniel's suggestion of moving out the blocks on the svn-repo (sounded quite ok), there seems to be an easy win based on the build-system we already have
- provide sample local.*.properties files for the various categories
- opt for one of those to become the default one (I guess deciding will depend on what is actually in those, or else content discussions will be fueled by this upfront decission)
all of which should at least ensure:
- that new blocks added do _not_ get automatically added to the build?
After doing some internal support on our projects here last week, I saw once again how difficult it is for people, even experienced ones, to strip down Cocoon to their needs.
The problem is that you have to know beforehand what blocks we want to use, compile them and -- here comes the real problem -- generate a cocoon.xconf. If you ever want to add or remove a block later on, you have to strip down the project's cocoon.xconf or merge it with the one that resulted from a new build with more blocks.
Sooo complicated and painful when there are so many components you don't even know what their use is. Result: all blocks are included in every project, which effectively makes Cocoon scary (not talking also of the slow startup).
So, enough is enough, I started this week-end to scracth something that has been itching me for long: being able to have one xconf snippet per block (including the core block), the main cocoon.xconf being just a set of imports of block-specific xconf snippets.
The result is that to activate/deactivate a block, you'll simply have to decomment/comment a line in the main cocoon.xconf. Example:
<cocoon>
<!-- block-specific components -->
<import src="cocoon-pdf-block.xconf"/>
<import src="cocoon-portal-block.xconf"/>
<import src="cocoon-svg-block.xconf"/>
<!-- the core cocoon components (parser, cache, pipelines, etc) --> <import src="cocoon-core.xconf"/> </cocoon>
The biggest problem is not related to the actual inclusion, but that some selectors can be fed by multiple blocks (e.g. source protocols provided by core, xmldb and databases blocks or taglibs provided by taglib and faces blocks).
So I started refactoring ECM++ so that a selector doesn't manage components itself but adds them to its service manager, and also delegates select() to this manager. This actually "flattens" the component space, thus allowing variations of a given role (what normally goes into selectors) to come from different sources. This is nearly done (still some problems for selectors nested in selectors), and <import> should come soon after.
WDYT?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
