cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Upgrade to Spring 2.5
Date Wed, 21 Nov 2007 21:05:05 GMT
Reinhard Poetz skrev:
> Since I've been running successfully two of my custom Cocoon 2.2 apps 
> with Spring 2.5-rc2 
> (, I 
> upgraded trunk to use Spring 2.5. Since it is aimed to be a drop-in 
> replacement for 2.0.x, I don't expect problems. Doing the upgrade now 
> gives us some time until we release Cocoon 2.2 final which is scheduled 
> for the end of the year.


> Now we can also think about merging Daniel's work on OSGi (whiteboard), 
> which requires Spring-OSGi, with trunk. Daniel, maybe you can share your 
> thoughts on what this would mean for trunk (build system, required code 
> changes, etc.) and how we can keep the experimental OSGi stuff out of 
> our releases.

I have not worked on it for a while so I don't remember all details. But 
the main part is making the cocoon jars bundles. This is preferably done 
with the Felix maven-bundle-plugin. I've written poms that contain the 
configuration of that plugin for all core blocks. The poms can be found 

Using the Felix maven-bundle-plugin will add OSGi and will 
not disturb non OSGi usage the slightest. So this can be done right away.

Second there are a number of spring-osgi configuration files that are 
placed in the META-INF/spring directories of the bundles. This directory 
isn't used in standard Cocoon, so these configuration files could also 
be added to trunk without cusing any problems.

For the Java code I add a package to the cocoon-servlet-service-impl 
that depends on the OSGi framework and some services. If we don't want 
such dependencies in trunk we could either add a special block for that 
package or have some compilation profile. There is also some code that 
is spring-osgi specific in 
I have tried to make the spring-osgi project interested in spring-osgi, 
but that seem to have low priority right now for them.

The main thing that I don't know how to solve is dependencies on 
bundelized versions of common libraries. I replace all the ordinary 
block dependencies with dependencies on bundelized versions of the 
libraries. By doing that I can use the Maven assembly plugin for 
collecting and installing all the needed bundle dependencies for the 
Cocoon block, so that it is easy to execute cocoon-osg, see

It would in most cases be possible to used the bundelized versions of 
the libraries for standard Cocoon as well. But the problem is that the 
bundelized jars in most cases not are released.

The bundelized Cocoon jars can be compiled with the standard 
dependencies in trunk. But in that case one have to depend explicitely 
on the bundelized version when creating thee cocoon-osgi assembly. This 
is rather inconvenient, but I don't see any other option if we want to 
move the OSGi stuff to trunk. Maybe one can do some clever thing with 
Maven profiles.


View raw message