Reinhard Poetz skrev:
Since I've been running successfully two of my custom Cocoon 2.2 apps with Spring 2.5-rc2 (http://opensource.atlassian.com/projects/spring/browse/SPR-4081), 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.
Great!
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 here http://svn.apache.org/repos/asf/cocoon/whiteboard/osgi/core/.
Using the Felix maven-bundle-plugin will add OSGi manifest.mf 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 http://svn.apache.org/repos/asf/cocoon/whiteboard/osgi/core/cocoon-spring-osgi/. 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 http://svn.apache.org/repos/asf/cocoon/whiteboard/osgi/cocoon-osgi-main/.
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.
/Daniel
