cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: [proposal] aiming to a naked cocoon
Date Tue, 11 Feb 2003 21:53:11 GMT
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


> - XMLForm

May be it should stay in core, don't know. -0.

> - Deli


> - 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 

> 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 


> 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.


> 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:
For additional commands, email:

View raw message