cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: M10N
Date Thu, 19 Jan 2006 11:01:11 GMT
Hash: SHA1

I've skimmed lots of code and am now hepefully more up-to-date as I was 
when writing the original mail.

On Thu, 19 Jan 2006, Reinhard Poetz wrote:

> Date: Thu, 19 Jan 2006 09:52:18 +0100
> From: Reinhard Poetz <>
> Reply-To:
> To:
> Subject: Re: M10N
> Giacomo Pati wrote:
>>  On Wed, 18 Jan 2006, Reinhard Poetz wrote:
>> >  Of course it's possible to edit the wiring.xml but I would (will) 
>> >  recommend
>>  Editing wiring.xml? I may now be totally wrong but I've understud that the
>>  wiring.xml is a generated file by the deployer (and the deployer-plugin
>>  uses the deployer). Please correct me if I'm wrong.
> yes, the wiring.xml is written by the deployer, but (usually) not directly 
> editid by the developer.

Yes, I've seen that

>> >  using the deployer as it will do validation, auto-wiring, ...
>>  Actually I think I'm quite confused about all those descriptors described
>>  in our Daisy and what the actual code looks like.
>>  pom.xml
>>    - for Maven build
>>    - used by deployer-plugin to resolve dependencies(?)
> pom.xml contains the necessary (usual) Java libraries and all blocks that 
> contain Java code. At deployment time pom.xml is only used to get usual Java 
> libraries (not blocks).


>>  block.xml
>>    - describes a block (components, sitemap, properties)
>>    - is used by blocks framework
> and used by the deployer to read default values for connections and 
> properties


>>  block-deploy.xml
>>    - defines block dependencies for deployer(-plugin)
>>    - supplies additional information (i.e. values for block properties)
>>    - is used by deployer-plugin to create the wiring.xml (?)
> block-deploy.xml describes which blocks you want to install and which 
> implementations you want to use for the requirements. As block.xml already 
> knows the default block, it can support auto-wiring. The result is the 
> wiring.xml.


>>  wiring.xml
>>    - configures a Cocoon app concerning block relationship, mount point,
>>      etc.
> and is only for internal use


>>  Please correct if I'm wrong.
>>  I'm not quite sure the difference between block-deploy.xml and wiring.xml.
>>  Is it that wiring.xml is the sum of all block-deploy.xml and their
>>  connections?
> The block deployer could support this but not the first release ;-)

I see now.

>>  Can you describe how you see all those descriptors look like
>>  for our super-sample-block (collection of all block samples) will look
>>  like?
> <deploy>
>   <block
>     id="ctemplate-samples"
>     urn="org.apache.cocoon:cocoon-template-samples:1.0.0"/>
>   <block
>     id="cforms-samples"
>     urn="org.apache.cocoon:cocoon-forms-samples:1.0.0"/>
>  [all other sample blocks]
> </deploy>

Yes, I would have come to this now myself, too.

> The deployer supports auto-wiring, which means that all required blocks will 
> be automatically deployed and added to wiring.xml.
> I hope that I can provide a first useable version of the 
> deployer-maven-plugin by the end of the week so that you (and others) can try 
> it out and that we find a balance between what should be configureable and 
> what not, which and how many configuration files we want, what they actually 
> configure and how they relate to each other.

Ahem.. I was working on the plugin for the simple-deploy goal. Are we 
stepping on each others toes?

What is the <cocoon> element in the block-deploy.xml 
for and how should the simple-deploy goal satisfy that.

- -- 
Giacomo Pati
Otego AG, Switzerland -
Orixo, the XML business alliance -
Version: GnuPG v1.4.2 (GNU/Linux)


View raw message