You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by Florian Müller <fl...@alfresco.com> on 2010/11/15 14:50:20 UTC
Client API refactoring branch merge
Hi all,
If nobody objects, I will merge the client API refactoring branch into
trunk this Wednesday.
If there are any reasons not to merge, please let me know as soon as
possible!
Cheers,
Florian
Re: Client API refactoring branch merge
Posted by Florian Müller <fl...@alfresco.com>.
reset() discards all changes made to the object.
refreshAndReset() discards all changes and refreshes the underlying
CmisObject.
Not sure if we need them. I thought they might be handy.
- Florian
On 22/11/2010 13:38, Florent Guillaume wrote:
> Yet another question:
>
> What's the expected semantics of
> org.apache.chemistry.opencmis.client.api.TransientCmisObject.reset()
> and refreshAndReset()?
>
> Florent
>
>
> On Wed, Nov 17, 2010 at 11:01 AM, Florian Müller
> <fl...@alfresco.com> wrote:
>> Hi all,
>>
>> Merge is done. Please test and provide feedback.
>>
>>
>> Thanks,
>>
>> Florian
>>
>>
>> On 15/11/2010 13:50, Florian Müller wrote:
>>>
>>> Hi all,
>>>
>>> If nobody objects, I will merge the client API refactoring branch into
>>> trunk this Wednesday.
>>> If there are any reasons not to merge, please let me know as soon as
>>> possible!
>>>
>>>
>>> Cheers,
>>>
>>> Florian
>>
>>
>
>
>
Re: Client API refactoring branch merge
Posted by Florent Guillaume <fg...@nuxeo.com>.
Yet another question:
What's the expected semantics of
org.apache.chemistry.opencmis.client.api.TransientCmisObject.reset()
and refreshAndReset()?
Florent
On Wed, Nov 17, 2010 at 11:01 AM, Florian Müller
<fl...@alfresco.com> wrote:
> Hi all,
>
> Merge is done. Please test and provide feedback.
>
>
> Thanks,
>
> Florian
>
>
> On 15/11/2010 13:50, Florian Müller wrote:
>>
>> Hi all,
>>
>> If nobody objects, I will merge the client API refactoring branch into
>> trunk this Wednesday.
>> If there are any reasons not to merge, please let me know as soon as
>> possible!
>>
>>
>> Cheers,
>>
>> Florian
>
>
--
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
Re: Client API refactoring branch merge
Posted by Florent Guillaume <fg...@nuxeo.com>.
Hi Florian,
On Thu, Nov 25, 2010 at 5:45 PM, Florian Müller
<fl...@alfresco.com> wrote:
> Well, I actually just completed what was unfinished before. Some interfaces
> were Serializable, some weren't.
> The interfaces don't have to be Serializable, but the implementations, that
> we are shipping have to be in order to support the HTTP session scenario.
> In other words, I don't see a strong reason to keep the interfaces
> Serializable. We could change that.
Ok, glad we're on the same page.
> On the other hand, how do you make sure that a statefull implementation
> behaves exactly like a the default stateless implementations? An application
> that uses the OpenCMIS interface should not have to care which
> implementation it is using underneath.
Agreed. In my case I have a set of unit test that test the same code
with AtomPub, SOAP and my local bindings.
> And, if the statefull implementation behaves like the stateless
> implementation, why is the local binding not sufficient? Are you hitting an
> issue with the local binding ?
The OpenCMIS-provided local bindings are implemented at the SPI level
(as they should) which means use of DocumentImpl, AbstractCmisObject,
ObjectDataImpl & co which have a heavy cost in terms of memory and
copying. By specializing the implementation I can directly reuse my
native objects and avoid a lot of overhead.
Florent
>
> - Florian
>
>
> On 25/11/2010 15:12, Florent Guillaume wrote:
>>
>> I'm still having a hard time coming to terms with some of the aspects
>> of the refactored code.
>>
>> I don't see why there's a link between a high-level interface like
>> CmisObject and the fact that it has to be Serializable.
>> Session/CmisObject/etc. are deemed "client" interfaces but they are
>> really only "high-level" interfaces, the API as opposed to the SPI.
>> The fact that the default implementation uses a stateless
>> client/server model (which allows for a Serializable implementation)
>> doesn't mean that all implementations have to be like that.
>>
>> In my local client bindings my implementations of these interfaces are
>> tied to a connection-like object which is not Serializable. And nobody
>> will try to put them in a HTTP session, it's perfectly all right for
>> them.
>>
>> So I'd like to remove the Serializable interface from Session,
>> CmisObject& co and put it on SessionImpl, AbstractCmisObject, etc.
>>
>> Florent
>>
>>
>> On Mon, Nov 22, 2010 at 3:44 PM, Florian Müller
>> <fl...@alfresco.com> wrote:
>>>
>>> The requirement that Session objects and objects attached it should be
>>> Serializable is not new. It has been there right from the beginning of
>>> OpenCMIS but wasn't implemented properly.
>>>
>>> We want to make sure that you can put a Session object into a
>>> HttpSession.
>>> That allows Servlet engines to swap out HttpSessions to disk or transfer
>>> sessions to other cluster nodes.
>>>
>>>
>>> - Florian
>>>
>>>
>>> On 22/11/2010 13:18, Florent Guillaume wrote:
>>>>
>>>> Another question:
>>>>
>>>> Why the new requirement that Session, CmisObject& co be Serializable?
>>>> In my local bindings, sessions and objects are created from
>>>> non-Serializable objects from the underlying repository API, and I
>>>> cannot easily make them truly Serializable. I have underlying
>>>> connection-like objects that come from a transactional context which
>>>> are definitely not Serializable.
>>>> What do you think?
>>>>
>>>> Florent
>>>>
>>>> On Wed, Nov 17, 2010 at 11:01 AM, Florian Müller
>>>> <fl...@alfresco.com> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Merge is done. Please test and provide feedback.
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Florian
>>>>>
>>>>>
>>>>> On 15/11/2010 13:50, Florian Müller wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> If nobody objects, I will merge the client API refactoring branch into
>>>>>> trunk this Wednesday.
>>>>>> If there are any reasons not to merge, please let me know as soon as
>>>>>> possible!
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Florian
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
--
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
Re: Client API refactoring branch merge
Posted by Florian Müller <fl...@alfresco.com>.
Hi Florent,
Well, I actually just completed what was unfinished before. Some
interfaces were Serializable, some weren't.
The interfaces don't have to be Serializable, but the implementations,
that we are shipping have to be in order to support the HTTP session
scenario.
In other words, I don't see a strong reason to keep the interfaces
Serializable. We could change that.
On the other hand, how do you make sure that a statefull implementation
behaves exactly like a the default stateless implementations? An
application that uses the OpenCMIS interface should not have to care
which implementation it is using underneath.
And, if the statefull implementation behaves like the stateless
implementation, why is the local binding not sufficient? Are you hitting
an issue with the local binding ?
- Florian
On 25/11/2010 15:12, Florent Guillaume wrote:
> I'm still having a hard time coming to terms with some of the aspects
> of the refactored code.
>
> I don't see why there's a link between a high-level interface like
> CmisObject and the fact that it has to be Serializable.
> Session/CmisObject/etc. are deemed "client" interfaces but they are
> really only "high-level" interfaces, the API as opposed to the SPI.
> The fact that the default implementation uses a stateless
> client/server model (which allows for a Serializable implementation)
> doesn't mean that all implementations have to be like that.
>
> In my local client bindings my implementations of these interfaces are
> tied to a connection-like object which is not Serializable. And nobody
> will try to put them in a HTTP session, it's perfectly all right for
> them.
>
> So I'd like to remove the Serializable interface from Session,
> CmisObject& co and put it on SessionImpl, AbstractCmisObject, etc.
>
> Florent
>
>
> On Mon, Nov 22, 2010 at 3:44 PM, Florian Müller
> <fl...@alfresco.com> wrote:
>> The requirement that Session objects and objects attached it should be
>> Serializable is not new. It has been there right from the beginning of
>> OpenCMIS but wasn't implemented properly.
>>
>> We want to make sure that you can put a Session object into a HttpSession.
>> That allows Servlet engines to swap out HttpSessions to disk or transfer
>> sessions to other cluster nodes.
>>
>>
>> - Florian
>>
>>
>> On 22/11/2010 13:18, Florent Guillaume wrote:
>>>
>>> Another question:
>>>
>>> Why the new requirement that Session, CmisObject& co be Serializable?
>>> In my local bindings, sessions and objects are created from
>>> non-Serializable objects from the underlying repository API, and I
>>> cannot easily make them truly Serializable. I have underlying
>>> connection-like objects that come from a transactional context which
>>> are definitely not Serializable.
>>> What do you think?
>>>
>>> Florent
>>>
>>> On Wed, Nov 17, 2010 at 11:01 AM, Florian Müller
>>> <fl...@alfresco.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Merge is done. Please test and provide feedback.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Florian
>>>>
>>>>
>>>> On 15/11/2010 13:50, Florian Müller wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> If nobody objects, I will merge the client API refactoring branch into
>>>>> trunk this Wednesday.
>>>>> If there are any reasons not to merge, please let me know as soon as
>>>>> possible!
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Florian
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
Re: Client API refactoring branch merge
Posted by Florent Guillaume <fg...@nuxeo.com>.
I'm still having a hard time coming to terms with some of the aspects
of the refactored code.
I don't see why there's a link between a high-level interface like
CmisObject and the fact that it has to be Serializable.
Session/CmisObject/etc. are deemed "client" interfaces but they are
really only "high-level" interfaces, the API as opposed to the SPI.
The fact that the default implementation uses a stateless
client/server model (which allows for a Serializable implementation)
doesn't mean that all implementations have to be like that.
In my local client bindings my implementations of these interfaces are
tied to a connection-like object which is not Serializable. And nobody
will try to put them in a HTTP session, it's perfectly all right for
them.
So I'd like to remove the Serializable interface from Session,
CmisObject & co and put it on SessionImpl, AbstractCmisObject, etc.
Florent
On Mon, Nov 22, 2010 at 3:44 PM, Florian Müller
<fl...@alfresco.com> wrote:
> The requirement that Session objects and objects attached it should be
> Serializable is not new. It has been there right from the beginning of
> OpenCMIS but wasn't implemented properly.
>
> We want to make sure that you can put a Session object into a HttpSession.
> That allows Servlet engines to swap out HttpSessions to disk or transfer
> sessions to other cluster nodes.
>
>
> - Florian
>
>
> On 22/11/2010 13:18, Florent Guillaume wrote:
>>
>> Another question:
>>
>> Why the new requirement that Session, CmisObject& co be Serializable?
>> In my local bindings, sessions and objects are created from
>> non-Serializable objects from the underlying repository API, and I
>> cannot easily make them truly Serializable. I have underlying
>> connection-like objects that come from a transactional context which
>> are definitely not Serializable.
>> What do you think?
>>
>> Florent
>>
>> On Wed, Nov 17, 2010 at 11:01 AM, Florian Müller
>> <fl...@alfresco.com> wrote:
>>>
>>> Hi all,
>>>
>>> Merge is done. Please test and provide feedback.
>>>
>>>
>>> Thanks,
>>>
>>> Florian
>>>
>>>
>>> On 15/11/2010 13:50, Florian Müller wrote:
>>>>
>>>> Hi all,
>>>>
>>>> If nobody objects, I will merge the client API refactoring branch into
>>>> trunk this Wednesday.
>>>> If there are any reasons not to merge, please let me know as soon as
>>>> possible!
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Florian
>>>
>>>
>>
>>
>>
>
>
--
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
Re: Client API refactoring branch merge
Posted by Florian Müller <fl...@alfresco.com>.
The requirement that Session objects and objects attached it should be
Serializable is not new. It has been there right from the beginning of
OpenCMIS but wasn't implemented properly.
We want to make sure that you can put a Session object into a
HttpSession. That allows Servlet engines to swap out HttpSessions to
disk or transfer sessions to other cluster nodes.
- Florian
On 22/11/2010 13:18, Florent Guillaume wrote:
> Another question:
>
> Why the new requirement that Session, CmisObject& co be Serializable?
> In my local bindings, sessions and objects are created from
> non-Serializable objects from the underlying repository API, and I
> cannot easily make them truly Serializable. I have underlying
> connection-like objects that come from a transactional context which
> are definitely not Serializable.
> What do you think?
>
> Florent
>
> On Wed, Nov 17, 2010 at 11:01 AM, Florian Müller
> <fl...@alfresco.com> wrote:
>> Hi all,
>>
>> Merge is done. Please test and provide feedback.
>>
>>
>> Thanks,
>>
>> Florian
>>
>>
>> On 15/11/2010 13:50, Florian Müller wrote:
>>>
>>> Hi all,
>>>
>>> If nobody objects, I will merge the client API refactoring branch into
>>> trunk this Wednesday.
>>> If there are any reasons not to merge, please let me know as soon as
>>> possible!
>>>
>>>
>>> Cheers,
>>>
>>> Florian
>>
>>
>
>
>
Re: Client API refactoring branch merge
Posted by Florent Guillaume <fg...@nuxeo.com>.
Another question:
Why the new requirement that Session, CmisObject & co be Serializable?
In my local bindings, sessions and objects are created from
non-Serializable objects from the underlying repository API, and I
cannot easily make them truly Serializable. I have underlying
connection-like objects that come from a transactional context which
are definitely not Serializable.
What do you think?
Florent
On Wed, Nov 17, 2010 at 11:01 AM, Florian Müller
<fl...@alfresco.com> wrote:
> Hi all,
>
> Merge is done. Please test and provide feedback.
>
>
> Thanks,
>
> Florian
>
>
> On 15/11/2010 13:50, Florian Müller wrote:
>>
>> Hi all,
>>
>> If nobody objects, I will merge the client API refactoring branch into
>> trunk this Wednesday.
>> If there are any reasons not to merge, please let me know as soon as
>> possible!
>>
>>
>> Cheers,
>>
>> Florian
>
>
--
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
Re: Client API refactoring branch merge
Posted by Florian Müller <fl...@alfresco.com>.
Hi Florent,
Actually, the contract and the JavaDoc are not the same for all methods.
Take getName() as an example. For CmisObject it returns the name of the
object as it was loaded. For TransientObject it returns the current
state of the name property in the transient object. If you have changed
the name and haven't saved the object yet, it doesn't return the name
that was loaded.
I have no strong opinion on the adapter design. Accepting an arbitrary
interface doesn't feel right to me, but if you have a use case, we can
change that.
- Florian
On 22/11/2010 09:56, Florent Guillaume wrote:
> Hi Florian,
>
> I agree that inheritance of implementation would be difficult.
> I was more thinking about inheritance of the interfaces. The contract
> is the same, the javadoc is the same, I really think the common
> interfaces shouldn't be duplicated (DRY). In that case having six new
> base interfaces would just clean things up IMHO.
>
> Regarding adapters, yes their implementation needs to be designed for
> CMIS, but not the interfaces. For instance you could adapt to
> InputStream to get a direct view of the content stream, or adapt to
> Map to get a Map-like view of the document's properties. Or adapt to
> pre-existing vendor interfaces.
>
> Florent
>
> On Fri, Nov 19, 2010 at 9:38 PM, Florian Müller
> <fl...@alfresco.com> wrote:
>> Hi Florent,
>>
>> Inheritance would be very difficult. The implementations of Document and
>> TransientDocument, for example, are too different.
>>
>> We could create common interfaces that cover all property getters. That
>> would clean up the existing interfaces a bit, but would also create six new
>> interfaces that I can't see a real use case for. Let me know if I'm missing
>> something.
>>
>> My idea behind the CmisObjectAdapter interface was to make the whole thing
>> more type save. Could you provide a sample use case that would require
>> reusing a third-party interface? Doesn't an adapter need to be designed for
>> CMIS?
>>
>>
>> - Florian
>>
>>
>> On 19/11/2010 18:58, Florent Guillaume wrote:
>>>
>>> Hi,
>>>
>>> There's a lot of duplication of methods from, for instance, Document
>>> and TransientDocument.
>>> Couldn't one inherit from the other (I guess not), or couldn't they
>>> have a common base interface?
>>>
>>> Also I don't think we need a base CmisObjectAdapter interface, it's
>>> actually useful to be able to adapt to any third-party interface. I'll
>>> deal with making getAdapter not need that (and use generics).
>>>
>>> Florent
>>>
>>>
>>> On Wed, Nov 17, 2010 at 11:01 AM, Florian Müller
>>> <fl...@alfresco.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Merge is done. Please test and provide feedback.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Florian
>>>>
>>>>
>>>> On 15/11/2010 13:50, Florian Müller wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> If nobody objects, I will merge the client API refactoring branch into
>>>>> trunk this Wednesday.
>>>>> If there are any reasons not to merge, please let me know as soon as
>>>>> possible!
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Florian
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
Re: Client API refactoring branch merge
Posted by Florent Guillaume <fg...@nuxeo.com>.
Hi Florian,
I agree that inheritance of implementation would be difficult.
I was more thinking about inheritance of the interfaces. The contract
is the same, the javadoc is the same, I really think the common
interfaces shouldn't be duplicated (DRY). In that case having six new
base interfaces would just clean things up IMHO.
Regarding adapters, yes their implementation needs to be designed for
CMIS, but not the interfaces. For instance you could adapt to
InputStream to get a direct view of the content stream, or adapt to
Map to get a Map-like view of the document's properties. Or adapt to
pre-existing vendor interfaces.
Florent
On Fri, Nov 19, 2010 at 9:38 PM, Florian Müller
<fl...@alfresco.com> wrote:
> Hi Florent,
>
> Inheritance would be very difficult. The implementations of Document and
> TransientDocument, for example, are too different.
>
> We could create common interfaces that cover all property getters. That
> would clean up the existing interfaces a bit, but would also create six new
> interfaces that I can't see a real use case for. Let me know if I'm missing
> something.
>
> My idea behind the CmisObjectAdapter interface was to make the whole thing
> more type save. Could you provide a sample use case that would require
> reusing a third-party interface? Doesn't an adapter need to be designed for
> CMIS?
>
>
> - Florian
>
>
> On 19/11/2010 18:58, Florent Guillaume wrote:
>>
>> Hi,
>>
>> There's a lot of duplication of methods from, for instance, Document
>> and TransientDocument.
>> Couldn't one inherit from the other (I guess not), or couldn't they
>> have a common base interface?
>>
>> Also I don't think we need a base CmisObjectAdapter interface, it's
>> actually useful to be able to adapt to any third-party interface. I'll
>> deal with making getAdapter not need that (and use generics).
>>
>> Florent
>>
>>
>> On Wed, Nov 17, 2010 at 11:01 AM, Florian Müller
>> <fl...@alfresco.com> wrote:
>>>
>>> Hi all,
>>>
>>> Merge is done. Please test and provide feedback.
>>>
>>>
>>> Thanks,
>>>
>>> Florian
>>>
>>>
>>> On 15/11/2010 13:50, Florian Müller wrote:
>>>>
>>>> Hi all,
>>>>
>>>> If nobody objects, I will merge the client API refactoring branch into
>>>> trunk this Wednesday.
>>>> If there are any reasons not to merge, please let me know as soon as
>>>> possible!
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Florian
>>>
>>>
>>
>>
>>
>
>
--
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
Re: Client API refactoring branch merge
Posted by Florian Müller <fl...@alfresco.com>.
Hi Florent,
Inheritance would be very difficult. The implementations of Document and
TransientDocument, for example, are too different.
We could create common interfaces that cover all property getters. That
would clean up the existing interfaces a bit, but would also create six
new interfaces that I can't see a real use case for. Let me know if I'm
missing something.
My idea behind the CmisObjectAdapter interface was to make the whole
thing more type save. Could you provide a sample use case that would
require reusing a third-party interface? Doesn't an adapter need to be
designed for CMIS?
- Florian
On 19/11/2010 18:58, Florent Guillaume wrote:
> Hi,
>
> There's a lot of duplication of methods from, for instance, Document
> and TransientDocument.
> Couldn't one inherit from the other (I guess not), or couldn't they
> have a common base interface?
>
> Also I don't think we need a base CmisObjectAdapter interface, it's
> actually useful to be able to adapt to any third-party interface. I'll
> deal with making getAdapter not need that (and use generics).
>
> Florent
>
>
> On Wed, Nov 17, 2010 at 11:01 AM, Florian Müller
> <fl...@alfresco.com> wrote:
>> Hi all,
>>
>> Merge is done. Please test and provide feedback.
>>
>>
>> Thanks,
>>
>> Florian
>>
>>
>> On 15/11/2010 13:50, Florian Müller wrote:
>>>
>>> Hi all,
>>>
>>> If nobody objects, I will merge the client API refactoring branch into
>>> trunk this Wednesday.
>>> If there are any reasons not to merge, please let me know as soon as
>>> possible!
>>>
>>>
>>> Cheers,
>>>
>>> Florian
>>
>>
>
>
>
Re: Client API refactoring branch merge
Posted by Florent Guillaume <fg...@nuxeo.com>.
Hi,
There's a lot of duplication of methods from, for instance, Document
and TransientDocument.
Couldn't one inherit from the other (I guess not), or couldn't they
have a common base interface?
Also I don't think we need a base CmisObjectAdapter interface, it's
actually useful to be able to adapt to any third-party interface. I'll
deal with making getAdapter not need that (and use generics).
Florent
On Wed, Nov 17, 2010 at 11:01 AM, Florian Müller
<fl...@alfresco.com> wrote:
> Hi all,
>
> Merge is done. Please test and provide feedback.
>
>
> Thanks,
>
> Florian
>
>
> On 15/11/2010 13:50, Florian Müller wrote:
>>
>> Hi all,
>>
>> If nobody objects, I will merge the client API refactoring branch into
>> trunk this Wednesday.
>> If there are any reasons not to merge, please let me know as soon as
>> possible!
>>
>>
>> Cheers,
>>
>> Florian
>
>
--
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
Re: Client API refactoring branch merge
Posted by Florian Müller <fl...@alfresco.com>.
Hi all,
Merge is done. Please test and provide feedback.
Thanks,
Florian
On 15/11/2010 13:50, Florian Müller wrote:
> Hi all,
>
> If nobody objects, I will merge the client API refactoring branch into
> trunk this Wednesday.
> If there are any reasons not to merge, please let me know as soon as
> possible!
>
>
> Cheers,
>
> Florian
Re: Client API refactoring branch merge
Posted by Florent Guillaume <fg...@nuxeo.com>.
Hi,
I should be fixing the rendition bug tonight or tomorrow, so a merge
on Wednesday is fine for me.
Florent
On Mon, Nov 15, 2010 at 2:50 PM, Florian Müller
<fl...@alfresco.com> wrote:
> Hi all,
>
> If nobody objects, I will merge the client API refactoring branch into trunk
> this Wednesday.
> If there are any reasons not to merge, please let me know as soon as
> possible!
>
>
> Cheers,
>
> Florian
>
--
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