cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Michels <step...@apache.org>
Subject Re: HackBlock refactor update: is this ok?
Date Tue, 27 Aug 2002 07:39:35 GMT


On Tue, 27 Aug 2002, Nicola Ken Barozzi wrote:

> I've decided to call the "modules" blocks, since many *are* blocks.
> Fop, Batik, etc are all blocks.
> For now they are HackBlocks ;-) because they don't yet have a final
> descriptor.
>
> The flowmap IMNSHO is not, so for now I'll leave it where it is.
>
> Now, I have done some experimentations with the dirs and the files.
>
> Example of the Fop block:
>   xml-cocoon2/src/blocks/java/org/apache/cocoon/serialization/FopSerializer
> xml-cocoon2/src/blocks/conf/fop.xmap
>
> in the Gump descriptor, which I want to move to Cocoon CVS, there is an
> entry for each block, stating dependencies in forms of jars and other
> blocks.
> There is a property file that says if a block should be compiled.
>
> Ant generates a build file that resolves the dependencies, builds the
> blocks one by one, and adds the xmap with the ant tool to the webapp.
>
> The samples in this way are still in webapp, and also the documentation.
>
> What do you think?
>
> Anything wrong? Anything missing?

I would also move the samples into the blocks dirs, like

 xml-cocoon2/src/blocks/fop/samples/samples.xml

I think this will be easier to exclude or include complete 'blocks'.
Excluding blocks will be an important thing for a minimal webapp target.

And do you really need a separate conf dir?

But go for it, I will try to help you ;-)

Stephan.


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


Mime
View raw message