cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Block deployment
Date Mon, 27 Feb 2006 15:43:52 GMT
Jean-Baptiste Quenot wrote:
> * Reinhard Poetz:


>>In the  future the  plugin will  also support  a "cocoon:deploy"
>>goal that  works based on  a configuration file  which describes
>>the blocks that should be installed and how they are configured.
> Isn't that exactly what we need to automate webapp build? How many
> Maven plugins are needed?  Just this one right?

yes, only that the "cocoon:deploy" goal does nothing ATM.

>>This configuration  file is based  on an  XML schema and  can be
>>unmarshalled  into  a  Java object. (I'm  using  Castor-XML  for
> Isn't it  just another pom.xml?   Do we  really need to  write yet
> another XML schema?

pom.xml describes *Java* *implementation* dependencies. But blocks will have a 
polymorphic behaviour. This means that a block doesn't depend on a 
implementation but on a contract. pom.xml (Maven 2) doesn't fit this requirement.

A block can depend on other blocks (polymorphic) and on components provided by 
other blocks (Java interfaces).

How this can be achieved isn't carved in stone yet. That's the reason why I 
stopped my work on the deployer until the contracts become clearer (hopefully soon).

>>Writing  some   Eclipse  plugin  in   order  to  get   a  visual
>>interface,  shouldn't be  too difficult  as it  can collect  the
>>same  information  as  the  content of  XML  file  would  be. Of
>>course  the Eclipse  plugin can  directly  call the  API of  the
>>deployer-core. For  now I've  stopped development  as I  have to
>>completly  understand what  the contract  of blocks  will be. As
>>soon as I know this, I will finish the deployer-core.
> What is  the advantage  of calling  the API  directly?  We  need a
> persistent storage to keep the blocks selection anyway.

yes, right

>>If you need/want to know more, just let me know! I don't know if
>>you have Eclipse plugin-development experience, but setting up a
>>project that does a simple deploy would be very helpful.
> Designing this plugin  should be feasible, I think  we could reuse
> part of [1]Lepido that helps to handle XML documents in an Eclipse
> plugin.


Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}



Telefonate ohne weitere Kosten vom PC zum PC:

View raw message