[CMIS-217] Initial OSGi support for OpenCMIS client (Atom only)

• Type: New Feature
• Status: Resolved
• Priority: Minor
• Resolution: Fixed
• Component/s: opencmis-client
• Labels: osgi

Environment

OSGi

• Assignee: Florian Müller
• Reporter: Jeremias Maerki
• Created: 16/Jun/10 09:12
• Updated: 04/Mar/11 14:22
• Resolved: 19/Jun/10 16:09

Description

The project I'm working on has a little hickup, so I haven't had the opportunity to go any further with my initial work on OSGi support for the CMIS client. So I would like to submit what I have so far in the hope it will be at least a spark to get full OSGi compatibility one day. I've not fully tested everything but it looks like the Atom binding works fine within OSGi (once all dependencies are installed anyway).

The SOAP binding won't work right now since there is a direct dependency on the JAX-WS RI and AFAIK there is no OSGi support for the RI, yet. So I've set the resolution for the com.sun.xml.ws.* classes to optional, i.e. there will be ClassNotFoundErrors when trying to use the SOAP binding. The attached patch also contains a change for org.apache.chemistry.opencmis.commons.impl.Converter, but that is untested and mostly a reminder to investigate if a direct dependency on the RI is really necessary. Please exclude that change when processing the patch if that doesn't make any sense.

Just a note for those not familiar with OSGi: all JARs will still work in a non-OSGi environment. Only chemistry-opencmis-client-impl got an additional dependency on the OSGi core API to register the ServiceFactory with the OSGi service registry. That's what the Activator class does. In a non-OSGi environment, this class will never be loaded so the OSGi core API doesn't have to be present in the class path. Long story short: Nothing changes for plain Java usage.

I hope this is useful and thanks for the preparative changes back in April.