cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorg Heymans>
Subject Re: Cocoon 2.2 - Build and deployment with Maven2
Date Sun, 04 Dec 2005 17:12:34 GMT

Reinhard Poetz wrote:

>                                       - o -
> +-------------------------------------------------------------------+
> |          Build and deployment from a Cocoon user's POV            |
> +-------------------------------------------------------------------+

>  +-- block.xml
>  +-- pom.xml
>  +-- src
>      +-- main
>      |   +-- java
>      |       +-- myApp
>      |           +--
>      |   +-- webapp
>      |       +-- sitemap.xmap
>      |       +-- hello.xml
>      +-- test
> Note that this follows the standard M2 project structure which makes the 
> M2 life much easier as it saves you configuration time (greetings from RoR).
yes. Include also src/main/resources , contents here gets automatically 
added to the classpath as well.

> The next step is adding your block to Cocoon application server by
> mvn cocoon:deploy
>  -Dserver=/home/rpoetz/cocoon2.2
>  -Dmount-point=/myBlock

at a later stage we could also provide

mvn cocoon:deploy

which would just fetch the block and install it.

> This will add an entry to the wiring.xml and will resolve all block 
> dependencies by putting them into the "<connections>" part.

I'm assuming it will deploy the block dependencies as well ?

> For Cocoon 2.2 this will also make sure that all library dependencies 
> specified in pom.xml are resolved.

If we hook in to the normal lifecycle then maven will resolve declared 
library dependencies for us. They should be available from the local 
repo by the time our deployer kicks in.

> Now you can start your Cocoon server and enter 
> http://[server]/myBlock/hello or
> http://[server]/myBlock/javaflow-hello
> If you want to use the block from other blocks you simply have to call
> mvn install
> and it is available for other local projects.

this standard maven goal would jar up the compiled project and put it as 
is in the local maven repo.

What do you mean by "use the block from other blocks", from 
IDE/container/... ?

>                                     - o -
> +-------------------------------------------------------------------+
> |             Build and deployment :: in depth                      |
> +-------------------------------------------------------------------+
> Now let's look a bit deeper into the implementation. A Cocoon block is
>  1. well, a valid Cocoon block by providing "block.xml"
>  2. a valid Maven2 artifact
>  3. a valid JAR file

IMO 2. and 3. are equivalent, or maybe i don't fully understand what a 
valid jar file encompasses.

> The jar (packaged block) has following content:
>  +-- block.xml
>  +-- myApp
>  |   +--
>  +-- sitemap.xmap
>  +-- hello.xml
>  +-- META-INF
>      +-- maven
>          +-- ...
>              +--
>              +-- pom.xml

Are you sure we want to include the sources in each block by default? By 
"packaged block" i'm assuming you're referring to the artifact that 
get's deployed to the repository for others to grab.

> Same should work for creating IDEA and Eclipse project properties files. 
> For the purpose of RAD, the output directory of the IDE can be set to the target
> directory of Maven.

maven creates idea and eclipse project files out of the box. These mojos 
are highly configurable so we wouldn't need to do much there.

> This requires special Maven goal. Thanks to Maven2 it has become very
> easy to write your own goals (they call them MOJOs). This goal will be 
> able to deploy a block and
>  - resolve all JAR dependencies (pom.xml)
>  - resolve all block dependencies (block.xml)
again i think if we hook up the deployer to the correct lifecycle phase 
the jar dependencies will be resolved already. Resolving the block 
dependencies should be trivial as at this point they are nothing but 
plain artifacts from a maven point of view.

> and copies (and for now unpacks) the block into
> /cocoon-app/WEB-INF/blocks/myBlock. And, in Cocoon 2.2 it will also copy 
> all JARs the block depends on into /WEB-INF/lib. The mojo has to be smart 
> enough to avoid JAR version conflicts. Thanks to the Maven naming conventions for 
> JARs this should be at least possible. (Note: OSGi will help us to overcome this
> problem once and for all).

> And Jorg, if you agree with my ideas, are the proposed changes difficult 
> to implement?

Thanks for the summary.

No I don't think any of this stuff is difficult to implement at all. 
Have a look at the ArtifactFactory for artifact resolution. maven's jar 
conflict strategy is pluggable so we should be able to reuse that as well.

Maybe you could start a block deployer directory in the whiteboard ?


View raw message