Below you explain the role of pom.xml and the role of block.xml. From a technology point of view, I can see why you are going this way.
However, if we think of a newcomer to Cocoon, I can see this as being unnecessarily complicated. Why are some things in pom.xml and others in block.xml? Well, er, because Maven doesn't know how to handle the stuff in block.xml. Would it not be possible to put the block.xml data somehow into the pom.xml file, and have it read by the block deployer mojo? Even if it were the same info just embedded into the pom.xml file, this would be substantially more user friendly, IMO. Does this make sense? Regards, Upayavira Reinhard Poetz wrote: > 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. > >>> 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 ;-) > >> 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> > > 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. >
