Stefano Mazzocchi wrote:
I think the cocoon core (aka 'naked cocoon') is defined by those classes that don't depend on any external library but those found in /lib/core and /lib/endorsed.
Everything else should be a block.
This allows us to create a build system where people can specify (at compile time) what they want to include into the system they are creating.
This is just a first step toward hot-deployable COBs, but it's important that we agree on what to factor out.
Looking into the current trunk, there are a few components that, IMO, should be moved to blocks.
They are:
- XMLDB stuff
+1
- XMLForm
May be it should stay in core, don't know. -0.
- Deli
+0
- XScript (what the hell is this anyway?)
Fancy stuff ;-)
SOAP logicsheet implemented on top of it.
I would merge XScript with session-fw, and would rename session-fw to something better reflecting its nature.
anything else I'm missing that should be factored out?
- XSLT. Must be pluggable. You should be able to choose either Xalan or SAXON.
Moreover, I propose to move the libraries that are block-related, into the block space, for example FOP will end up being in
/src/block/fop/lib/fop-xxx.jar
+1
and so on and each block will have its own build file (not the current build system generated by an XSLT stylesheet)
+0 - haven't look into current build yet. Vadim
This will make it easier to migrate the blocks when a better component architecture will be in place after we release cocoon 2.1
What do you think?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
