You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Andreas Pieber <an...@gmx.at> on 2009/03/03 20:39:49 UTC

Re: [c3] osginize jars

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

Re: [c3] osginize jars

Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,

On Tue, Mar 3, 2009 at 8:39 PM, Andreas Pieber <an...@gmx.at> wrote:
> ...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....

We do this in Sling, see [1] which builds a webapp, starts it during
Maven's integration-test phase and runs various tests against it. It's
a bit slow but useful. You probably need a full build of Sling if you
want to play with that though.

I don't see a reason why you couldn't start and embedded Felix
framework in unit testing either, but don't have an example readily
available.

-Bertrand

[1] http://svn.apache.org/repos/asf/incubator/sling/trunk/launchpad/testing/