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 >
