That was the Cocoon GetTogether 2007 Rome

After two interesting Hackathon days, Friday was reserved for the ‘official’ program. After doing my keynoteCocoon 2.2 – A long Journey“, Francesco Chicchiriccò did a presentation “Hands on Cocoon“. He was talking about a lot of projects that he implemented based on Cocoon. Quite impressive and showed me again how powerful Cocoon is.

Jasha Joachimsthal continued with “Create your website in 5 minutes with the Cocoon Project Wizard“. Since he was talking about Cocoon 2.1, it was interessting to listen to his analysis of what needs to be improved and compare it with that what Cocoon 2.2 offers. I’m happy to say that he will find a lot of cool stuff and that we have established contracts on things that have been unspecified yet.

The next one was Bertrand Delacretaz with “XSLT and XPath – without the pain!“. Since XSLT is heavily used in Cocoon applications I don’t think that people heard a lot of new things. Though the interesting thing was how Bertrand structured his presentation. I’m sure that this will help many of us who do trainings on XSLT to get ideas how to make it easier for newbies to understand this different programming language.

Lars Trieloff was talking about “DAX – Where flowscript and XSLT meet“. DAX stands for Declarative API for XML. The idea is to make it easy for others to write transformations in more familiar languages like Java or Javascript. Since I’m fluent in XSLT this wouldn’t be that appealing for me. The interesting point for me is that you can get access to the outside world (e.g. a Spring bean) very easily which I was missing once and then before. Obviously there is a Cocoon integration in the form of a transformer. After thinking about it for a while I’m not sure if I recommend the usage of DAX because it is too easy to implement side effects. Hmmmm.

Vadim Gritsenko showed how you can use Cocoon 2.2 the classic way.  Of course that’s not recommended for new projects, but if you have  an already existing Cocoon 2.1 application and want to migrate to the latest and greatest stuff, then his guide is more than helpful. I hope that he finds some time to start off writing a migration guide.

After having a great meal next to the hippos and elephants (the GT took place in a Zoo!), Carsten Ziegeler and Bertrand Delacretaz gave a presentation titled “Bye bye Avalon: an introduction to OSGi“. They explained the motivation behind component based applications and how they devloped over time. Finally the closed the session with a simple OSGi example.

For some of us a deja vu, Daniel Fagerstrom was talking (again) about Cocoon OSGi. After a first attempt two years ago he is working again on this stuff. Thanks to Apache Felix and the Spring-OSGi subproject he has already come rather far. The way things are going his work can be merged into trunk by the end of the year. But don’t be worried about having to learn all this new stuff when you want to work with Cocoon 2.2. We will still fully support the conventional way of using only Spring as sole container too.

The next speaker was Lars Trieloff talking about “Mindquarry Collaboration Software“. Mindquarry uses a huge stack of technologies (SVN, Jackrabitt, Dojo, Jackrabitt, SubethaSMTP, etc.) and Cocoon is playing the role of clueing all the things together. The most interesting parts of his presentations were his lessons learned. As it shows the devil is very often in the details. When working on an architecture it really pays off if you are well acquainted with the technologies that you pull together.

Jeremy Quinn did the last presentation of the day talking titled “Break my site: Practical Stress Testing and Tuning of Cocoon Applications“. The information he gave wasn’t in particular Cocoon specific though useful for everybody who builds web applications.

Find most of the presentations available as downloads at the Cocoon Wiki.


Cocoon 2.2 – A long Journey (CocoonGT 2007 Keynote)

This year I had the honour of doing my second keynote presentation for a Cocoon GetTogether. On popular demand I was talking about Cocoon 2.2 and the developer’s motivations behind all the new stuff:

  • Spring 2.0 as component container
  • the Servlet-Service framework that establishes contracts in modular web applications
    (no dependency on Cocoon core – easily resuseable outside the Cocoon world)
  • Easier configuration using the Spring Configurator. There is no need for patching XML configuration files.
    (no dependency on Cocoon core – easily resuseable outside the Cocoon world)
  • Easier development
    • three Maven 2 archetypes available to give  your Cocoon 2.2 project a jump start
    • run any Cocoon 2.2  block using the Cocoon Maven plugin which allows reload of any resources, also Java classes and Spring bean defintions

Here is my presentation as a PDF.


Cocoon 2.2: A new architecture

Last week the vote for Cocoon 2.2-RC2 passed and I’m happy to announce the release of it. Actually Cocoon 2.2 isn’t the big monolith that you might know from the 2.1.x or 2.0.x series. We have been working hard to make Cocoon more modular:

Apache Cocoon 2.2 Architecture

From a first glance the most significant change has been that since version 2.2 Cocoon is based on the Spring 2 framework. We also introduced two new subprojects:

Both can be easily used without Cocoon Core.

Cocoon Core has been put on top of those two frameworks and “only” provides pipelines, sitemaps, out-of-the-box caching support and the most important sitemap components. Everything that goes beyond that has been moved into its own block. Also custom Cocoon applications are build as blocks.

So what’s a block in Cocoon 2.2? You might be familiar with the term block from Cocoon 2.1. In 2.1 a block was a unit to modularize the build system. Starting with 2.2 a block has become more: A block has become the unit of modularization (Eclipse uses the term plugins, OSGi bundles) in Cocoon and can provide the following services:

  • general servlet services (any servlet can be managed by the Cocoon servlet-service framework),
  • special services that provide pipelines as services,
  • component services (Spring beans, Avalon services/components),
  • a container for classes and resources (e.g. sitemaps, templates, images, etc.).

A block is packaged as a Java archive (jar) following certain conventions concerning the directory structure. So adding a block to your Cocoon application only means adding it as a dependency and all the services (see above), Java classes and recourses become available automatically.

Are you curious? There are a bunch of tutorials that help you to get started!


Indoqa house-warming party

A little bit late but yesterday we celebrated the foundation of Indoqa. It was really cool that so many people followed my invitation and came to our office in the 9th district of Vienna. Here are some photos:

Matthias, Michael, Reinhard

Matthias, Michael, Reinhard

Brigitte, Hans-Georg, Reinhard

Hans-Georg and hise wife Brigitte, Reinhard

… and then we moved to 7 Cocktails:

Indoqa house warming party


Christa, Dietmar, Astrid

Indoqa house warming party

Reinhard, Matthias