You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by "Klevenz, Stephan" <st...@sap.com> on 2011/08/01 17:11:22 UTC

Re: OSGi Bundles for InMemroy Server

Hi,

in meantime I could finish OSGi bundling of the OpenCmis server part and
code is ready to be merged into trunk.

Actually I did add a OSGi wrappers on top of OpenCmis managed in a new
maven module. Existing artifacts are more or less not touched.

There is now one OSGi client and one server bundle. Both bundles include
required OpenCmis JARs and for that the Bundle-ClassPath of the manifest
is maintained. Apart the transitive dependencies they are self-contained.

There are some issues:
- Client is bundled twice a) the new self-contained bundle and b) the
already existing bundles of the single jars (client api, impl ...).
- The server projects with the war packaging are split to separate the
classes packaging. Unfortunately I had difficulties to wrap the wars using
the Felix bundle plugin.
- I could test the bundling only for the AtomPub binding. For the
webservices my runtime misses the Sun XMLs stuff.

svn branch:        
https://svn.apache.org/repos/asf/chemistry/opencmis/branches/server-osgi-en
ablement/chemistry-opencmis-osgi/
related Jira issue: https://issues.apache.org/jira/browse/CMIS-400

If there are no objections then I will integrate the branch into trunk
ASAP.

Regards,
Stephan






>Sounds good to me Stephan!
>
>Jens
>
>-----Original Message-----
>From: Klevenz, Stephan [mailto:stephan.klevenz@sap.com]
>Sent: Freitag, 15. Juli 2011 08:47
>To: dev@chemistry.apache.org
>Subject: RE: OSGi Bundles for InMemroy Server
>
>In principle I agree. Unfortunately this is not straight forward. The
>problem is that the WAR is a build by <packaging>par</packaging> while
>OSGi enabled JAR results from another build with
><packaging>jar</packaging>. So, it is not easy to get both in one POM.
>
>I would like to finalize the OSGi enablement first and then I will try to
>eliminate the secondary WAR build.
>
>Stephan
>
>-----Original Message-----
>From: Jens Hübel [mailto:jhuebel@opentext.com]
>Sent: Donnerstag, 14. Juli 2011 23:45
>To: dev@chemistry.apache.org
>Subject: RE: OSGi Bundles for InMemroy Server
>
>Maybe naive, but do we really need a separate project for this? Isn't
>there a way to generate both versions out of one pom.xml?
>
>
>-----Original Message-----
>From: Klevenz, Stephan [mailto:stephan.klevenz@sap.com]
>Sent: Donnerstag, 14. Juli 2011 10:36
>To: dev@chemistry.apache.org
>Subject: OSGi Bundles for InMemroy Server
>
>Hi Chemistries,
>
>I have started to work on OSGi bundelization of the OpenCmis server parts
>and in special I would like to run the InMemory server as bundle in
>Eclipse target runtime. In detail I would like to separate code from
>InMemory server WAR packaging and create a OSGi bundle for the code part.
>
>If there are no objections then I will start development in a separate
>branch and open a JIRA feature issue for that.
>
>Regards,
>Stephan
>
>
>
>


Re: OSGi Bundles for InMemroy Server

Posted by Florian Müller <fl...@alfresco.com>.
+1

I'd like to see it in trunk.


Florian


On 01/08/2011 16:11, Klevenz, Stephan wrote:
> Hi,
> 
> in meantime I could finish OSGi bundling of the OpenCmis server part and
> code is ready to be merged into trunk.
> 
> Actually I did add a OSGi wrappers on top of OpenCmis managed in a new
> maven module. Existing artifacts are more or less not touched.
> 
> There is now one OSGi client and one server bundle. Both bundles include
> required OpenCmis JARs and for that the Bundle-ClassPath of the manifest
> is maintained. Apart the transitive dependencies they are self-contained.
> 
> There are some issues:
> - Client is bundled twice a) the new self-contained bundle and b) the
> already existing bundles of the single jars (client api, impl ...).
> - The server projects with the war packaging are split to separate the
> classes packaging. Unfortunately I had difficulties to wrap the wars using
> the Felix bundle plugin.
> - I could test the bundling only for the AtomPub binding. For the
> webservices my runtime misses the Sun XMLs stuff.
> 
> svn branch:        
> https://svn.apache.org/repos/asf/chemistry/opencmis/branches/server-osgi-en
> ablement/chemistry-opencmis-osgi/
> related Jira issue: https://issues.apache.org/jira/browse/CMIS-400
> 
> If there are no objections then I will integrate the branch into trunk
> ASAP.
> 
> Regards,
> Stephan
> 
> 
> 
> 
> 
> 
>> Sounds good to me Stephan!
>>
>> Jens
>>
>> -----Original Message-----
>> From: Klevenz, Stephan [mailto:stephan.klevenz@sap.com]
>> Sent: Freitag, 15. Juli 2011 08:47
>> To: dev@chemistry.apache.org
>> Subject: RE: OSGi Bundles for InMemroy Server
>>
>> In principle I agree. Unfortunately this is not straight forward. The
>> problem is that the WAR is a build by <packaging>par</packaging> while
>> OSGi enabled JAR results from another build with
>> <packaging>jar</packaging>. So, it is not easy to get both in one POM.
>>
>> I would like to finalize the OSGi enablement first and then I will try to
>> eliminate the secondary WAR build.
>>
>> Stephan
>>
>> -----Original Message-----
>> From: Jens Hübel [mailto:jhuebel@opentext.com]
>> Sent: Donnerstag, 14. Juli 2011 23:45
>> To: dev@chemistry.apache.org
>> Subject: RE: OSGi Bundles for InMemroy Server
>>
>> Maybe naive, but do we really need a separate project for this? Isn't
>> there a way to generate both versions out of one pom.xml?
>>
>>
>> -----Original Message-----
>> From: Klevenz, Stephan [mailto:stephan.klevenz@sap.com]
>> Sent: Donnerstag, 14. Juli 2011 10:36
>> To: dev@chemistry.apache.org
>> Subject: OSGi Bundles for InMemroy Server
>>
>> Hi Chemistries,
>>
>> I have started to work on OSGi bundelization of the OpenCmis server parts
>> and in special I would like to run the InMemory server as bundle in
>> Eclipse target runtime. In detail I would like to separate code from
>> InMemory server WAR packaging and create a OSGi bundle for the code part.
>>
>> If there are no objections then I will start development in a separate
>> branch and open a JIRA feature issue for that.
>>
>> Regards,
>> Stephan
>>
>>
>>
>>
>