cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [proposal] aiming to a naked cocoon
Date Wed, 12 Feb 2003 08:36:47 GMT

Stefano Mazzocchi wrote, On 11/02/2003 22.32:
> 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.

Yes, that's IIUC the current agreement.

> Looking into the current trunk, there are a few components that, IMO, 
> should be moved to blocks.
> 
> They are:
> 
> - XMLDB stuff
> 
> - XMLForm
> 
> - Deli
> 
> - XScript (what the hell is this anyway?)

+1 to all

Gianugo IIRC had a block done for XMLDB and didn't commit it.
Gianugo?

> anything else I'm missing that should be factored out?

The environments. The depend on other jars, like the servlet one.
I would like to see them factored out into src/environments, as 
previously suggested.

Also the ServletGenerator, and most important the StreamGenerator which 
depends on servlets! Remember?

The last conclusion IIRC was to add getting the inputstream in the 
environment, and additional ones in a container-specific way.

Other things will become apparent later.

> 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

Or put in place the downloading of jars from a repository.

> and so on and each block will have its own build file (not the current 
> build system generated by an XSLT stylesheet)

That was done to ensure that we could use the same build system for Gump 
and our build.

Separating builds of similar projects is a worse mess, look at 
Excalibur. If we separate buildfiles it will be a mess to update them, 
and from a management perspective it sucks. I'm -1 in separating the 
buildfiles, but +1 in making the current system better and more cleanly 
layered.

> This will make it easier to migrate the blocks when a better component 
> architecture will be in place after we release cocoon 2.1


-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message