+1 Florian
-----Original Message----- From: Florent Guillaume [mailto:f...@nuxeo.com] Sent: Donnerstag, 29. April 2010 04:36 To: chemistry-dev Subject: Re: Issues with OSGi-compatibility in OpenCMIS Client Thanks Jeremias for the OSGi work, this is indeed nice. I agree with you guys that we can move SessionFactoryImpl into client.runtime without a problem. Everyone has autocompletion in their IDE anyway, so it's not a big deal I think. I'm also in favor of moving SessionFactory to client.api. I can do it if there's consensus but people don't have time to work on it. Florent On Wed, Apr 28, 2010 at 9:57 PM, Stephan Klevenz <step...@klaeff.de> wrote: > Hi Jerimias, > > Thanks for bringing OSGi into discussion. This is very interesting. > > When we decided to moved the SessionFactoryImpl into the client package then > we did not consider OSGi. One reason for that was because of the session is > some kind of entry point into API and in the client package it is just easy > to find. I think we can revert this decision and move back the factory to the > runtime package. What do others think? > > Well, I'm not really an OSGi expert and that is why I'm asking another > question. OpenCMIS depends on other artifacts that are not OSGi bundles. For > example JAX-WS is a plain set of libraries. How will be this dependencies > handled within a OSGi container? > > Regards, > Stephan > > > Am 28.04.2010 um 17:45 schrieb Jeremias Maerki: > >> Hi there, >> >> I hope I'm not duplicating someone else's work, but I've started to add >> OSGi metadata and other OSGi-related wiring (starting with the client), >> so OpenCMIS can eventually be deployed in an OSGi container. I'm happy >> to offer these changes to the project if there's interest. >> >> The problem I'm facing right now is that the SessionFactory interface >> and the SessionFactoryImpl class are both in the same package: >> org.apache.chemistry.opencmis.client >> That creates a collision which makes it impossible to consume a >> SessionFactory service published to the OSGi service registry, since an >> internal compatibility check fails and no service is returned. >> >> The problem would easily be solved by moving SessionFactoryImpl to the >> "runtime" subpackage. But I must also say that I don't really see the >> point to have SessionFactory alone in the "client" package when all the >> other related interfaces are in the "api" subpackage. I'd be happy, >> though, if we could at least move SessionFactoryImpl as indicated above. >> >> WDYT? >> >> Thanks, >> Jeremias Maerki >> > > -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
