cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Cocoon 2.2 - Build and deployment with Maven2
Date Sun, 04 Dec 2005 14:36:32 GMT

IIUC Daniel did some great work so that we get feature complete for Cocoon 2.2. 
The last missing pice is a proper build and deployment system for the things 
called block.

Last days I had some time to look into Maven2 and I have to say that
I'm impressed. They finally overcome the limitations of Maven1 which was in my
opinion some "high-level-Ant" as maven files looked in some more complex
project very similar to its Ant pendants. Maven2 is now able to completly
*describe* a project based on a build life cycle. It still has some problems
with report generations but I'm sure the Maven folks will clear this the next

I want to share my thoughts on how to use Maven2. Jorg's work so far focuses on
the build part - I'd like to draw the big picture including build, RAD and 
deployment together with the options Cocoon 2.2 (--> blocks) offers. I will 
provide two views, the user's view and some in-depth view on what has to be done.

                                       - o -

Before I start with the both views, I have to draw your attention to one 
fundamental change which is important to understand. So far we agreed that the 
structure of a block looks like this:

  +-- block.xml
      +-- classes

I was one of the proponents of it but my opinion has changed for one

        a Cocoon block isn't a valid JAR file any more

as this makes many things complicated like

  - IDE integration
  - Maven2 build process

(Yes Daniel, your gut feeling that we should do it this way was right ;-)

                                       - o -

|          Build and deployment from a Cocoon user's POV            |

You first start with an Maven archetype goal:

mvn archetype:create

This creates a skeleton of a Cocoon block (--> nearly everything in Cocoon 2.2
will be a block, also your Cocoon-based applications) that is a good starting 
point and an already working block:

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

The next step is adding your block to Cocoon application server by

mvn cocoon:deploy

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

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

Now you can start your Cocoon server and enter http://[server]/myBlock/hello or

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.

                                     - 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

What we have to do is providing a Maven goal that creates a correct artifact and
makes sure that all above points are considered. It should also check that 
block.xml and pom.xml are consistent.

The jar (packaged block) has following content:

  +-- block.xml
  +-- myApp
  |   +--
  +-- sitemap.xmap
  +-- hello.xml
  +-- META-INF
      +-- maven
          +-- ...
              +-- pom.xml

(Note: Maybe we should move all the Cocoon resources into some sub directory.
Maybe there is some way to make it even invisible for the classloader.)

The maven build process works out of the box because all dependencies (blocks 
and JARs) of a block can be resolved by Maven itself. No additional work should 
be required.

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.

What we need in Cocooon is some kind of deployment facility as outlined above.
Blocks are put into /cocoon-app/WEB-INF/blocks/myBlock and the use of blocks is
configured by wiring.xml.

The block deployer must be able to

  - deploy a single block
  - create a complete, reproducible Cocoon installation

For now I will concentrate on the single block installation.

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)

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

                                         - o -

The functionality of the block deployer is partly already available. I will
start to work on it again, by mavenizing the deployer itself. Then I will 
provide a simple Maven2 wrapper and will rework the library integration by 
switching over to Maven repositories as AFAICS they cover everything we need.

Addionally I want to make the ReloadingClassloader available for all "local" blocks.

                                         - o -

Feedback would be very appreciated, especially whether I haven't overlooked 
something important.

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

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

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

View raw message