-----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 <[EMAIL PROTECTED]>
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-----
