cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Pieber <a...@gmx.at>
Subject Re: [c3] osginize jars
Date Tue, 03 Mar 2009 19:39:49 GMT
Hi,

I'm not finished at the moment but I want to give a sign of life :) I'm still 
working on this issue and want provide an actual state here:

1) I've added the felix-bundle-plugin to each cocoon3-module.

  This works very smoothly.

2) I've taken a very detailed look at all generated MANIFEST.mf files

  I've done this to the best of my knowledge and I was not able to find any 
errors at the generated MANIFEST files.

3) I've tested pipelining with cocoon-sax and cocoon-stax in Equinox (or to be 
more detailed an eclipse rcp application) and apache felix

  Also no problem with this in java6 (since the required stax classes are 
provided by the JRE). Nevertheless this introduces an issue in java5 since 
woodstox is required (at the moment) which is not packaged as an OSGi bundle 
(A possible solution to this issue later on...).

4) I've tried to find a way to fire up all bundles (no they are ;) ) in an 
apache-felix engine and start the unit-tests there.

  I've made some researches at this topic too, but there's no way to way to 
fire up a apache-felix engine by maven and run all unit tests in it. I think 
one solution could be to do this task by an script...


Another problem is that some "higher level components" as cocoon-sitemap and 
cocoon-optional (also cocoon-stax in java5) require libraries which are not 
osginized at the moment. The apache-felix-bundle plugin provides the 
possibility to add libraries to the pathes of bundles and package them with 
the main components. Of course this has two huge disadvantages. First of all 
it makes the bundles huger than required for an non-OSGi-runtime-enviroment 
and secondly it duplicates libraries in non-OSGi-enviroments which is at least 
as worse as the size of the components. Also two solutions came into my mind: 
One to provide an own profile for building osginized cocoon-components which 
includes all required libraries into the bundles or redistributing the 
required components (as far the lizense allows it). But I'm neither happy with 
the first idea nor with the second one. Any further ideas here?

I've attached a patch osginizing all jar files. Using this patch works quite 
fine for embedding an sax/stax pipline in an OSGi environment. I've to say 
that I've tried this only for a very simple use case (generator-serializer) 
since I still like to run all unit tests in an OSGi environment -.-

Finally I want to solve two huge issues before I'll provide a "final" patch:

 * fire up an apache-felix-engine and run the unit tests there (with an 
script)
 * find a solution for the "packaging-problem" (references to non osgi-
components)

As soon I'll have any further information I'll share it here. Nevertheless I'm 
very interested in what you think and your ideas about that...

Andreas

Mime
View raw message