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                   [EMAIL PROTECTED]
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to