Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Thu, 19 Jan 2006 12:01:11 +0100 (CET)
From: Giacomo Pati <giacomo@apache.org>
Sender: giacomo@lapgp.otego.com
To: dev@cocoon.apache.org
Subject: Re: M10N
In-Reply-To: <43CF5342.4000103@apache.org>
Message-ID: <Pine.LNX.4.64.0601191153000.8982@lapgp.otego.com>
References: <Pine.LNX.4.64.0601171508340.9674@lapgp.otego.com>
 <43CDEB1C.6000002@apache.org>
 <Pine.LNX.4.64.0601180836530.8982@lapgp.otego.com>
 <43CE09B5.6020406@apache.org>
 <Pine.LNX.4.64.0601181054140.8982@lapgp.otego.com>
 <43CE18A8.8040800@apache.org>
 <Pine.LNX.4.64.0601181148590.8982@lapgp.otego.com>
 <43CF5342.4000103@apache.org>
X-GPG-PUBLIC_KEY: 
 http://pks.gpg.cz:11371/pks/lookup?op=get&search=0x2CD749BD98E35590
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

-----BEGIN PGP SIGNED MESSAGE-----
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 <reinhard@apache.org>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> 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).

Ok.

>>  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

Yup.

>>  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.

Ok.

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

Yes.

>>  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 - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDz3F9LNdJvZjjVZARAq83AJ0RSjhM7hSa0xPumH40OzT3YeklSQCgw8IX
/mcgpFD9WL4Y0NCrEC4UQJM=
=XfbG
-----END PGP SIGNATURE-----