Done.
http://svn.apache.org/viewvc?rev=939300&view=rev


On Thu, Apr 29, 2010 at 2:55 PM, Florian Müller <[email protected]> wrote:
> +1
>
> Florian
>
> -----Original Message-----
> From: Florent Guillaume [mailto:[email protected]]
> 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 <[email protected]> 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
>



-- 
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

Reply via email to