You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/08/27 09:26:51 UTC
HackBlock refactor update: is this ok?
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?
--
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
Re: HackBlock refactor update: is this ok?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephan Michels wrote:
>
> 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.
If I put the samples here, the link would still be broken in the webapp,
and moreover the block would depend for the samples on the sample webapp
as a container... hmmm, I don't like it much...
I don't see it as a big problem to keep the samples in webapp for the
moment, when we get right the block mounting with the block
pseudo-protocol we mught move them in the blocks... no?
> And do you really need a separate conf dir?
I had the same feeling :-)
I would put all configuration in xml-cocoon2/src/blocks/fop/ directly, no?
> But go for it, I will try to help you ;-)
:-)
Please be patient a bit more.
As soon as I commit the first working block, we can split our workload :-)
--
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
Re: HackBlock refactor update: is this ok?
Posted by Stephan Michels <st...@apache.org>.
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