You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by Ugo Cei <u....@sourcesense.com> on 2009/12/11 14:35:25 UTC
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
On Dec 10, 2009, at 4:00 PM, Florent Guillaume wrote:
> My earlier recommendation to Paul and Florian, and my recommendation
> today, is that, if incubating is deemed the better choice, OpenCMIS
> become a top level directory under the Chemistry codebase. The earlier
> the two codebases are brought together, the earlier we can start
> factoring things (and there are quite a few boilerplates in the CMIS
> spec). IMHO it would also be nice if the high-level APIs could
> converge, as they are what the Java programmer will see and, when it
> makes sense, we should reduce confusion.
Here's my +1 from the peanut gallery. I personally don't find the idea of incubating OpenCMIS appealing at all.
Ugo
--
Ugo Cei
Sourcesense - making sense of Open Source: http://www.sourcesense.com
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Florent Guillaume <fg...@nuxeo.com>.
On Fri, Dec 11, 2009 at 7:10 PM, Florian Müller <fm...@opentext.com> wrote:
> But you are actually comparing two different levels of APIs. The opencmis-provider-api handles simple immutable data objects while chemistry-api follows an object-oriented approach. As far as I know Chemistry has nothing comparable to the opencmis-provider-api.
The Chemistry SPI class provides a data-transfer-object-based API that
is similar to opencmis-provider-api although implemented very
differently.
> The opencmis-client-api would be the right level to look at but the code of this API is not in SVN yet. We will make available on Monday.
> The APIs are not the main reason why I think that Chemistry and OpenCMIS are different. (I would like to avoid the word "superior". I never used that in this context. Both projects came from a different background that's why they are different.)
> Chemistry uses Abdera to communicate with the server while OpenCMIS is based on JAX-B and some CMIS specific XML coding.
Actually no, the Chemistry client side doesn't use Abdera, it uses an
ad-hoc StAX-based serialization. Currently the server side still uses
Abdera but I'd like to make this go away and use StAX as well, as
Abdera is very heavy and costly (and not well extensible).
>There is a lot of code sharing between the AtomPub and the Web Services binding. (I couldn't find a Web Services client in Chemistry. So I can't comment on that.)
Indeed in Chemistry the AtomPub client code doesn't use JAX-B based
serialization so doesn't share code with SOAP. JAX-B makes for a lot
of intermediate objects whose structure depends on the XML you want to
generate, which is fine for SOAP but doesn't seem right to me when
designing an API from scratch. I wanted the APIs to be as Java-ish as
possible and hide the underlying XML structural choices as much as
possible.
>OpenCMIS has a caching infrastructure that is specific to CMIS and how OpenCMIS work. There is nothing like that in Chemistry.
Yes Chemistry has no caching yet, this will be added later at the
level of the high-level API implementation. For me it's not the role
of the SPI to do caching.
Florent
> The overall architecture and principals below the API are very, very different. Bringing both together would require philosophy changes on both sides. I'm not saying that this isn't possible, but it's a lengthy process.
>
> We derived our design from a lot of prototypes and applications that we have built over the past 20 months. Some code fragments and concepts are actually pretty old now. We had a lot of it in one shape or another when Chemistry started. That's why Chemistry was never an option for us. The code bases of Chemistry and OpenCMIS have been developed at the same time taking different routes. Chemistry did that in the public, most of OpenCMIS was created behind closed doors.
>
> Here we are with a working code base that we cannot give up and that we will maintain in the future for obvious reasons. Our idea was to make it Open Source and let others benefit from our work. Apache seemed to be the right place - at least three days ago. It was never meant to be an attack against Chemistry.
>
>
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Jens Hübel <jh...@opentext.com>.
Hey Jukka,
let's discuss some of the technical areas how to continue.
> Would it at least make sense for the projects to share a common
> org.apache.cmis package with with things like constants defined in the
> CMIS standard and other basic concepts that everyone can agree with?
Definitely there are areas where sharing makes sense. The constants, etc are probably the simplest pieces. I see some more:
Query Parser:
Chemistry did a pretty good job with the query parser. Currently with focus on client side maybe not on our top list, but I do not see any reason to implement this a second time. And this is one of the more complex sub-projects.
Web Service:
Not sure how far you are here. But the provider implementation should be functional complete in regards of the WS binding. You should take a closer look if you see any chance to benefit from this.
Caching:
If I got it right there is no Caching yet in Chemistry. Caching (at least of the type system) is probably crucial for an acceptable performance of any CMIS implementation. We already have some form of caching, perhaps not yet the most sophisticated one. This will highly depend on the internal object structure that is cached, but I assume that at least parts of the code can be shared.
This list isn't complete but this comes into my mind right now.
We also should outline some more of the design differences:
> Indeed in Chemistry the AtomPub client code doesn't use JAX-B based
> serialization so doesn't share code with SOAP.
This is very different compared to the OpenCMIS approach. Both bindings use the same XML and our intent was to share as much as possible between SOAP and Atom and keep the binding specifics to a minimum. The consumer of the API should not see a difference between the two bindings. On top of the JAXB generated class we have handcrafted APIs and implementations. As Florian pointed out we favor a two-level approach here with data transfer classes (being stateless with the exception of caching) and a stateful object-oriented client API.
Testing:
As mentioned above the client should not be aware of the binding in use. Our tests are therefore consumers of the API and agnostic to the binding. There would be an ObjectServiceTest but not an AtomXYZtest. What I see in Chemistry is a TCK based on AtomPub and directly operating on feeds etc. Is it intended to continue this way or is this more an interim step (you need to start with testing somewhere)? BTW our code isn't totally clean in this regard as well yet.
AtomPub and Web Service:
Looking at the chemistry code this seems to be (currently) focused very much on AtomPub. One of the OpenCMIS design goals is to treat both protocol bindings equally. WS is a first class citizen for OpenCMIS. What are the plans for Chemistry in regards of web services?
And as far as I remember one question is still unanswered:
What is the intended way in Chemistry how a client API consumer controls when a request to the server is made? Do you have any design around this so far?
Jens
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Jens Hübel <jh...@opentext.com>.
Hi Jukka,
> It's a
> bit unfortunate that we now have two codebases for pretty much the
> same thing, but I guess we just have to live with that for now. In
> fact some healthy competition may even be good for both projects.
There is no doubt that life would have been easier for all of us if all participants in the CMIS standard would have had the same open source tradition like those currently engaged in the Apache Chemistry project. But the fact that CMIS is able to break barriers in the relation of more traditional oriented software companies is something that shouldn't be underestimated IMHO. However we end in managing the fragmentation, let's benefit from this. And I think that's what Florent and others also pointed out.
> To do that, I'd
> be happy to help mentor OpenCMIS either as a part of Chemistry or as a
> separate podling.
That's great to hear!
Jens
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Jens Hübel <jh...@opentext.com>.
Hey Jukka,
let's discuss some of the technical areas how to continue.
> Would it at least make sense for the projects to share a common
> org.apache.cmis package with with things like constants defined in the
> CMIS standard and other basic concepts that everyone can agree with?
Definitely there are areas where sharing makes sense. The constants, etc are probably the simplest pieces. I see some more:
Query Parser:
Chemistry did a pretty good job with the query parser. Currently with focus on client side maybe not on our top list, but I do not see any reason to implement this a second time. And this is one of the more complex sub-projects.
Web Service:
Not sure how far you are here. But the provider implementation should be functional complete in regards of the WS binding. You should take a closer look if you see any chance to benefit from this.
Caching:
If I got it right there is no Caching yet in Chemistry. Caching (at least of the type system) is probably crucial for an acceptable performance of any CMIS implementation. We already have some form of caching, perhaps not yet the most sophisticated one. This will highly depend on the internal object structure that is cached, but I assume that at least parts of the code can be shared.
This list isn't complete but this comes into my mind right now.
We also should outline some more of the design differences:
> Indeed in Chemistry the AtomPub client code doesn't use JAX-B based
> serialization so doesn't share code with SOAP.
This is very different compared to the OpenCMIS approach. Both bindings use the same XML and our intent was to share as much as possible between SOAP and Atom and keep the binding specifics to a minimum. The consumer of the API should not see a difference between the two bindings. On top of the JAXB generated class we have handcrafted APIs and implementations. As Florian pointed out we favor a two-level approach here with data transfer classes (being stateless with the exception of caching) and a stateful object-oriented client API.
Testing:
As mentioned above the client should not be aware of the binding in use. Our tests are therefore consumers of the API and agnostic to the binding. There would be an ObjectServiceTest but not an AtomXYZtest. What I see in Chemistry is a TCK based on AtomPub and directly operating on feeds etc. Is it intended to continue this way or is this more an interim step (you need to start with testing somewhere)? BTW our code isn't totally clean in this regard as well yet.
AtomPub and Web Service:
Looking at the chemistry code this seems to be (currently) focused very much on AtomPub. One of the OpenCMIS design goals is to treat both protocol bindings equally. WS is a first class citizen for OpenCMIS. What are the plans for Chemistry in regards of web services?
And as far as I remember one question is still unanswered:
What is the intended way in Chemistry how a client API consumer controls when a request to the server is made? Do you have any design around this so far?
Jens
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Dec 11, 2009 at 7:10 PM, Florian Müller <fm...@opentext.com> wrote:
> But you are actually comparing two different levels of APIs. The
> opencmis-provider-api handles simple immutable data objects while
> chemistry-api follows an object-oriented approach. As far as I know
> Chemistry has nothing comparable to the opencmis-provider-api.
I wouldn't say so. For example, here's how you get selected properties
of an object in a given repository (assuming I've understood the APIs
correctly):
OpenCMIS:
CmisProvider provider = ...;
ObjectService service = provider.getObjectService();
PropertiesData data = service.getProperties(
"repositoryId", "objectId", "filter", ...);
Map<String, PropertyData<?>> properties = data.getProperties();
Chemistry:
RepositoryService service = ...;
SPI spi = service.getRepository("repositoryId").getSPI();
ObjectEntry entry = spi.getProperties(
spi.newObjectId("objectId"), new Inclusion("filter", ...));
Map<String, Serializable> properties = entry.getValues();
I'd don't think the APIs are too different. At least they certainly
are comparable.
Would it at least make sense for the projects to share a common
org.apache.cmis package with with things like constants defined in the
CMIS standard and other basic concepts that everyone can agree with?
> We derived our design from a lot of prototypes and applications that we
> have built over the past 20 months. Some code fragments and concepts
> are actually pretty old now. We had a lot of it in one shape or another when
> Chemistry started. That's why Chemistry was never an option for us.
> The code bases of Chemistry and OpenCMIS have been developed at the
> same time taking different routes. Chemistry did that in the public, most
> of OpenCMIS was created behind closed doors.
This paragraph should definitely go into the OpenCMIS proposal. It
gives a much clearer rationale for the separate project than the API
and scope differences mentioned in the original proposal.
I definitely understand the value of the existing code base. It's a
bit unfortunate that we now have two codebases for pretty much the
same thing, but I guess we just have to live with that for now. In
fact some healthy competition may even be good for both projects. In
the interest of avoiding further fragmentation I'd like for us to find
ways for the two projects to coexists and cooperate. To do that, I'd
be happy to help mentor OpenCMIS either as a part of Chemistry or as a
separate podling.
BR,
Jukka Zitting
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Dec 11, 2009 at 7:10 PM, Florian Müller <fm...@opentext.com> wrote:
> But you are actually comparing two different levels of APIs. The
> opencmis-provider-api handles simple immutable data objects while
> chemistry-api follows an object-oriented approach. As far as I know
> Chemistry has nothing comparable to the opencmis-provider-api.
I wouldn't say so. For example, here's how you get selected properties
of an object in a given repository (assuming I've understood the APIs
correctly):
OpenCMIS:
CmisProvider provider = ...;
ObjectService service = provider.getObjectService();
PropertiesData data = service.getProperties(
"repositoryId", "objectId", "filter", ...);
Map<String, PropertyData<?>> properties = data.getProperties();
Chemistry:
RepositoryService service = ...;
SPI spi = service.getRepository("repositoryId").getSPI();
ObjectEntry entry = spi.getProperties(
spi.newObjectId("objectId"), new Inclusion("filter", ...));
Map<String, Serializable> properties = entry.getValues();
I'd don't think the APIs are too different. At least they certainly
are comparable.
Would it at least make sense for the projects to share a common
org.apache.cmis package with with things like constants defined in the
CMIS standard and other basic concepts that everyone can agree with?
> We derived our design from a lot of prototypes and applications that we
> have built over the past 20 months. Some code fragments and concepts
> are actually pretty old now. We had a lot of it in one shape or another when
> Chemistry started. That's why Chemistry was never an option for us.
> The code bases of Chemistry and OpenCMIS have been developed at the
> same time taking different routes. Chemistry did that in the public, most
> of OpenCMIS was created behind closed doors.
This paragraph should definitely go into the OpenCMIS proposal. It
gives a much clearer rationale for the separate project than the API
and scope differences mentioned in the original proposal.
I definitely understand the value of the existing code base. It's a
bit unfortunate that we now have two codebases for pretty much the
same thing, but I guess we just have to live with that for now. In
fact some healthy competition may even be good for both projects. In
the interest of avoiding further fragmentation I'd like for us to find
ways for the two projects to coexists and cooperate. To do that, I'd
be happy to help mentor OpenCMIS either as a part of Chemistry or as a
separate podling.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Florent Guillaume <fg...@nuxeo.com>.
On Fri, Dec 11, 2009 at 7:10 PM, Florian Müller <fm...@opentext.com> wrote:
> But you are actually comparing two different levels of APIs. The opencmis-provider-api handles simple immutable data objects while chemistry-api follows an object-oriented approach. As far as I know Chemistry has nothing comparable to the opencmis-provider-api.
The Chemistry SPI class provides a data-transfer-object-based API that
is similar to opencmis-provider-api although implemented very
differently.
> The opencmis-client-api would be the right level to look at but the code of this API is not in SVN yet. We will make available on Monday.
> The APIs are not the main reason why I think that Chemistry and OpenCMIS are different. (I would like to avoid the word "superior". I never used that in this context. Both projects came from a different background that's why they are different.)
> Chemistry uses Abdera to communicate with the server while OpenCMIS is based on JAX-B and some CMIS specific XML coding.
Actually no, the Chemistry client side doesn't use Abdera, it uses an
ad-hoc StAX-based serialization. Currently the server side still uses
Abdera but I'd like to make this go away and use StAX as well, as
Abdera is very heavy and costly (and not well extensible).
>There is a lot of code sharing between the AtomPub and the Web Services binding. (I couldn't find a Web Services client in Chemistry. So I can't comment on that.)
Indeed in Chemistry the AtomPub client code doesn't use JAX-B based
serialization so doesn't share code with SOAP. JAX-B makes for a lot
of intermediate objects whose structure depends on the XML you want to
generate, which is fine for SOAP but doesn't seem right to me when
designing an API from scratch. I wanted the APIs to be as Java-ish as
possible and hide the underlying XML structural choices as much as
possible.
>OpenCMIS has a caching infrastructure that is specific to CMIS and how OpenCMIS work. There is nothing like that in Chemistry.
Yes Chemistry has no caching yet, this will be added later at the
level of the high-level API implementation. For me it's not the role
of the SPI to do caching.
Florent
> The overall architecture and principals below the API are very, very different. Bringing both together would require philosophy changes on both sides. I'm not saying that this isn't possible, but it's a lengthy process.
>
> We derived our design from a lot of prototypes and applications that we have built over the past 20 months. Some code fragments and concepts are actually pretty old now. We had a lot of it in one shape or another when Chemistry started. That's why Chemistry was never an option for us. The code bases of Chemistry and OpenCMIS have been developed at the same time taking different routes. Chemistry did that in the public, most of OpenCMIS was created behind closed doors.
>
> Here we are with a working code base that we cannot give up and that we will maintain in the future for obvious reasons. Our idea was to make it Open Source and let others benefit from our work. Apache seemed to be the right place - at least three days ago. It was never meant to be an attack against Chemistry.
>
>
--
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: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability
Services (CMIS)
Posted by Michael Wechner <mi...@wyona.com>.
Florent Guillaume wrote:
> On Fri, Dec 11, 2009 at 11:18 PM, Michael Wechner
> <mi...@wyona.com> wrote:
>
>> Right and as long as OpenCMIS fulfills the requirements of the incubator I
>> don't see any reason why there shouldn't be two projects of the same topic.
>>
>> I also do not see any reason why OpenCMIS should be a sub-project of
>> Chemistry.
>> Give it a chance of its own within the current rules of the incubator and it
>> will either work or not.
>> If it works, then graduate, if not, then remove it.
>>
>
> My concern is that if there are two separate svn trees then factoring
> things between the two projects will be much harder. Let's not kid
> ourselves, having two different maven release cycles, and having
> dependencies to foreign SNAPSHOT projects, will not help. To me it's a
> waste of time and effort.
>
> Let me ask the question differently: what's lost by having the code in
> the Chemistry svn tree?
>
Beside that I agree with Joe's email I would additionally argue that you
can easily share code without being
within the same project and having it separate from each other it forces
you to make
the architecture/code even better, which I think has (nearly) only
advantages.
Cheers
Michael
> Florent
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Stefane Fermigier <sf...@nuxeo.com>.
So basically what you mean is: "competition, over collaboration" ?
S.
On Dec 12, 2009, at 6:55 PM, Joe Schaefer wrote:
> ----- Original Message ----
>
>> From: Florent Guillaume <fg...@nuxeo.com>
>> To: general@incubator.apache.org
>> Cc: chemistry-dev@incubator.apache.org
>> Sent: Sat, December 12, 2009 10:35:18 AM
>> Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
>> Interoperability Services (CMIS)
>>
>> On Fri, Dec 11, 2009 at 11:18 PM, Michael Wechner
>> wrote:
>>> Right and as long as OpenCMIS fulfills the requirements of the
>>> incubator I
>>> don't see any reason why there shouldn't be two projects of the
>>> same topic.
>>>
>>> I also do not see any reason why OpenCMIS should be a sub-project of
>>> Chemistry.
>>> Give it a chance of its own within the current rules of the
>>> incubator and it
>>> will either work or not.
>>> If it works, then graduate, if not, then remove it.
>>
>> My concern is that if there are two separate svn trees then factoring
>> things between the two projects will be much harder. Let's not kid
>> ourselves, having two different maven release cycles, and having
>> dependencies to foreign SNAPSHOT projects, will not help. To me
>> it's a
>> waste of time and effort.
>>
>> Let me ask the question differently: what's lost by having the code
>> in
>> the Chemistry svn tree?
>
> Sovereignty over the codebase for one. At this point I don't see
> why people
> are so concerned with the (lack of) alignment with Chemistry. If the
> people
> who wish to work on this proposal prefer to go it alone for the time
> being,
> so be it. If a community doesn't emerge out of one project or the
> other,
> it's an easier decision to make at that time then it is to predict
> in advance
> right now.
>
>
>
>
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
New: follow me on Twitter: http://twitter.com/sfermigier
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Stefane Fermigier <sf...@nuxeo.com>.
So basically what you mean is: "competition, over collaboration" ?
S.
On Dec 12, 2009, at 6:55 PM, Joe Schaefer wrote:
> ----- Original Message ----
>
>> From: Florent Guillaume <fg...@nuxeo.com>
>> To: general@incubator.apache.org
>> Cc: chemistry-dev@incubator.apache.org
>> Sent: Sat, December 12, 2009 10:35:18 AM
>> Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
>> Interoperability Services (CMIS)
>>
>> On Fri, Dec 11, 2009 at 11:18 PM, Michael Wechner
>> wrote:
>>> Right and as long as OpenCMIS fulfills the requirements of the
>>> incubator I
>>> don't see any reason why there shouldn't be two projects of the
>>> same topic.
>>>
>>> I also do not see any reason why OpenCMIS should be a sub-project of
>>> Chemistry.
>>> Give it a chance of its own within the current rules of the
>>> incubator and it
>>> will either work or not.
>>> If it works, then graduate, if not, then remove it.
>>
>> My concern is that if there are two separate svn trees then factoring
>> things between the two projects will be much harder. Let's not kid
>> ourselves, having two different maven release cycles, and having
>> dependencies to foreign SNAPSHOT projects, will not help. To me
>> it's a
>> waste of time and effort.
>>
>> Let me ask the question differently: what's lost by having the code
>> in
>> the Chemistry svn tree?
>
> Sovereignty over the codebase for one. At this point I don't see
> why people
> are so concerned with the (lack of) alignment with Chemistry. If the
> people
> who wish to work on this proposal prefer to go it alone for the time
> being,
> so be it. If a community doesn't emerge out of one project or the
> other,
> it's an easier decision to make at that time then it is to predict
> in advance
> right now.
>
>
>
>
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
New: follow me on Twitter: http://twitter.com/sfermigier
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Florent Guillaume <fg...@nuxeo.com>
> To: general@incubator.apache.org
> Cc: chemistry-dev@incubator.apache.org
> Sent: Sat, December 12, 2009 10:35:18 AM
> Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
>
> On Fri, Dec 11, 2009 at 11:18 PM, Michael Wechner
> wrote:
> > Right and as long as OpenCMIS fulfills the requirements of the incubator I
> > don't see any reason why there shouldn't be two projects of the same topic.
> >
> > I also do not see any reason why OpenCMIS should be a sub-project of
> > Chemistry.
> > Give it a chance of its own within the current rules of the incubator and it
> > will either work or not.
> > If it works, then graduate, if not, then remove it.
>
> My concern is that if there are two separate svn trees then factoring
> things between the two projects will be much harder. Let's not kid
> ourselves, having two different maven release cycles, and having
> dependencies to foreign SNAPSHOT projects, will not help. To me it's a
> waste of time and effort.
>
> Let me ask the question differently: what's lost by having the code in
> the Chemistry svn tree?
Sovereignty over the codebase for one. At this point I don't see why people
are so concerned with the (lack of) alignment with Chemistry. If the people
who wish to work on this proposal prefer to go it alone for the time being,
so be it. If a community doesn't emerge out of one project or the other,
it's an easier decision to make at that time then it is to predict in advance
right now.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability
Services (CMIS)
Posted by Michael Wechner <mi...@wyona.com>.
Florent Guillaume wrote:
> On Fri, Dec 11, 2009 at 11:18 PM, Michael Wechner
> <mi...@wyona.com> wrote:
>
>> Right and as long as OpenCMIS fulfills the requirements of the incubator I
>> don't see any reason why there shouldn't be two projects of the same topic.
>>
>> I also do not see any reason why OpenCMIS should be a sub-project of
>> Chemistry.
>> Give it a chance of its own within the current rules of the incubator and it
>> will either work or not.
>> If it works, then graduate, if not, then remove it.
>>
>
> My concern is that if there are two separate svn trees then factoring
> things between the two projects will be much harder. Let's not kid
> ourselves, having two different maven release cycles, and having
> dependencies to foreign SNAPSHOT projects, will not help. To me it's a
> waste of time and effort.
>
> Let me ask the question differently: what's lost by having the code in
> the Chemistry svn tree?
>
Beside that I agree with Joe's email I would additionally argue that you
can easily share code without being
within the same project and having it separate from each other it forces
you to make
the architecture/code even better, which I think has (nearly) only
advantages.
Cheers
Michael
> Florent
>
>
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Florent Guillaume <fg...@nuxeo.com>
> To: general@incubator.apache.org
> Cc: chemistry-dev@incubator.apache.org
> Sent: Sat, December 12, 2009 10:35:18 AM
> Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
>
> On Fri, Dec 11, 2009 at 11:18 PM, Michael Wechner
> wrote:
> > Right and as long as OpenCMIS fulfills the requirements of the incubator I
> > don't see any reason why there shouldn't be two projects of the same topic.
> >
> > I also do not see any reason why OpenCMIS should be a sub-project of
> > Chemistry.
> > Give it a chance of its own within the current rules of the incubator and it
> > will either work or not.
> > If it works, then graduate, if not, then remove it.
>
> My concern is that if there are two separate svn trees then factoring
> things between the two projects will be much harder. Let's not kid
> ourselves, having two different maven release cycles, and having
> dependencies to foreign SNAPSHOT projects, will not help. To me it's a
> waste of time and effort.
>
> Let me ask the question differently: what's lost by having the code in
> the Chemistry svn tree?
Sovereignty over the codebase for one. At this point I don't see why people
are so concerned with the (lack of) alignment with Chemistry. If the people
who wish to work on this proposal prefer to go it alone for the time being,
so be it. If a community doesn't emerge out of one project or the other,
it's an easier decision to make at that time then it is to predict in advance
right now.
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Florent Guillaume <fg...@nuxeo.com>.
On Fri, Dec 11, 2009 at 11:18 PM, Michael Wechner
<mi...@wyona.com> wrote:
> Right and as long as OpenCMIS fulfills the requirements of the incubator I
> don't see any reason why there shouldn't be two projects of the same topic.
>
> I also do not see any reason why OpenCMIS should be a sub-project of
> Chemistry.
> Give it a chance of its own within the current rules of the incubator and it
> will either work or not.
> If it works, then graduate, if not, then remove it.
My concern is that if there are two separate svn trees then factoring
things between the two projects will be much harder. Let's not kid
ourselves, having two different maven release cycles, and having
dependencies to foreign SNAPSHOT projects, will not help. To me it's a
waste of time and effort.
Let me ask the question differently: what's lost by having the code in
the Chemistry svn tree?
Florent
--
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: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sun, Dec 13, 2009 at 8:41 PM, Joe Schaefer <jo...@yahoo.com> wrote:
> When Etch was proposed they didn't even mention Thrift, even tho they both basically
> have the same goals.
1. Etch and Thrift are not involved in specs, and more comparable to
"web app framework" domain.
2. Etch is also not in a good state, in reality due to initial
diversity problems.
And my *claim* is that Avalon was shut down due to exactly this. Two
smaller communities wanted to part ways (diff impl of the same
"spec"), and Board slapped us so hard on the head it wasn't funny. Am
I bitter? No. But I think lack of consistency is not to be taken
lightly. For me, the Board's message/actions set a precedent and
acting as my guide to what the ASF is about and not.
I am surprised Noel has forgotten this episode already ;-)
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Niclas Hedhman <ni...@hedhman.org>
> To: general@incubator.apache.org
> Sent: Sat, December 12, 2009 9:42:21 PM
> Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
>
> The Board has in the past condemned "balkanization" of community, and my
> take on this situation is exactly that.
>
> This is not "yet another web framework", which often brought forward as
> examples that the ASF encourages competition within. Those typically have a
> different "angle", "approach" or "metaphor", something making each very
> different beasts. But in this case we are talking about "the same spec".
> There is no real distinguishing features and huge overlap of commonality.
>
> I think this is a NIH-syndrome in play, in the best case "oh we have the
> code working already" and the worst case "we don't like to collaborate with
> them", and there is reason to think that that goes for both sides of the
> fence.
>
> I want to see Chemistry capable to absorb such contribution and collaborate
> heavily to bring such codebase in.
> And I want to see the people of the OpenCMIS proposal to show that they
> indeed can work with others.
>
> Exactly how the merged community goes about with the technical integration
> is its own business, but I am worried that the new codebase will not receive
> the welcome I hope, the Chemistry base will dominate, and the OpenCMIS
> proposer get fed up and leaves. Important Mentors understand the risks here,
> and keep eyes extra open for attrition, domination and forceful
> consensus-seeking.
>
> I think discussion should continue on Chemistry dev@ list. If agreement
> can't be reached there, then I am NOT in favor of incubating OpenCMIS
> separately and will vote -1 to such proposal. I will also form myself an
> opinion of how well Chemistry is trying to collaborate, and it may improve
> or deteriorate its status with me.
>
> This can become an excellent opportunity for all involved to show off their
> ApacheWay skills
I really wish we would confine ourselves to things we understand, and agree with
Michael that the injection of platitutes or ultimatums does not help things along.
When Etch was proposed they didn't even mention Thrift, even tho they both basically
have the same goals. When Doug decided to create Avro instead of participating in
Thrift the board didn't wince, not even a little bit.
If anything it's time for the people behind the OpenCMIS proposal to do more of the
talking, and the people on the IPMC (and in Chemistry IMO) to do less of it.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability
Services (CMIS)
Posted by Michael Wechner <mi...@wyona.com>.
Niclas Hedhman wrote:
> The Board has in the past condemned "balkanization" of community, and my
> take on this situation is exactly that.
>
> This is not "yet another web framework", which often brought forward as
> examples that the ASF encourages competition within. Those typically have a
> different "angle", "approach" or "metaphor", something making each very
> different beasts. But in this case we are talking about "the same spec".
> There is no real distinguishing features and huge overlap of commonality.
>
there isn't just one JCR implementation and I am glad there is a choice
and some healthy competition.
Yes, the ASF only hosts one JCR implementation, but would it matter if
another would be part of the ASF?
I don't think it would matter, but it would rather show that the ASF is
really open-minded about different approaches.
> I think this is a NIH-syndrome in play, in the best case "oh we have the
> code working already" and the worst case "we don't like to collaborate with
> them", and there is reason to think that that goes for both sides of the
> fence.
>
if so, then let's be specific on this and parties should explain
themselves re this particular "allegation"
> I want to see Chemistry capable to absorb such contribution and collaborate
> heavily to bring such codebase in.
> And I want to see the people of the OpenCMIS proposal to show that they
> indeed can work with others.
>
> Exactly how the merged community goes about with the technical integration
> is its own business, but I am worried that the new codebase will not receive
> the welcome I hope, the Chemistry base will dominate, and the OpenCMIS
> proposer get fed up and leaves. Important Mentors understand the risks here,
> and keep eyes extra open for attrition, domination and forceful
> consensus-seeking.
>
> I think discussion should continue on Chemistry dev@ list. If agreement
> can't be reached there, then I am NOT in favor of incubating OpenCMIS
> separately and will vote -1 to such proposal.
that seems to me very wrong. If you have two folks speaking to each
other and in the end they find out
that they cannot work together for some reason, then we send one of them
into the "desert" just because
the other one was there first (especially if you have enough space
actually). Let's first see how the discussion
goes and then decide how to continue.
> I will also form myself an
> opinion of how well Chemistry is trying to collaborate, and it may improve
> or deteriorate its status with me.
>
> This can become an excellent opportunity for all involved to show off their
> ApacheWay skills
>
I would be glad if we could stop refering to the ApacheWay, because
AFAIK there is no strict definition of
the ApacheWay. I would rather prefer if we could be specific, for
example that both parties make a concrete list,
where they are different code-wise and why they think it is not possible
to merge the code initially and also make
a plan what the common "interfaces" could be initially and in the future.
Thanks
Michael
> -- Niclas
>
> On 13 Dec 2009 09:47, "Emmanuel LŽcharny" <el...@gmail.com> wrote:
>
> Joe Schaefer a écrit :
>
>
>> <snip/>
>>
>>
>>>>>> I see where Joe is going to with his "let both project get in and
>>>>>>
>> let's see which one will su...
>>
>>
> I must admit that it's human nature, but I think - but I'm probably
> optimistic - that people working on an apache project should overcome this
> reluctance. In this very case, as Chemistry has entered the incubator more
> than 6 months ago, I can understand that 'merging' with OpenCMIS would slow
> down the process, and OTOH, OpenCMIS may not like the idea to be seen as a
> sub-project... But this is the Incubator, the perfect place yo work out such
> problems. My fear is that by accepting two separate projects, one may die
> (or even both), because of the lack of community... It seems less likely if
> both project work out a common solution, IMHO.
>
> Collaboration does not kill good ideas...
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: g...
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by David Nuescheler <da...@gmail.com>.
hi all,
here are my two cents.
i believe the cmis community is too small to fork at this point
and at least the chemistry part of the community does not want
to fork (at least that's my take, as a part of it).
so i would personally assume that all chemistry committers
would join the opencmis initial committers even before the incubation
starts and would actively work in a true commuity effort to consolidate
the efforts. the mentors and champions would probably be the
same people aswell.
so in my mind the bottom-line would be same result as if we had the
opencmis people join chemistry, except that we give infra a bit
of extra work and create extra effort for the incubator from a reporting
perspective...
i am sure we can find a good way forward between the two communities.
we just need a couple of days to sort things out...
keep in mind we all know each other personally ;)
regards,
david
On Sun, Dec 13, 2009 at 10:16 AM, ant elder <an...@gmail.com> wrote:
> On Sun, Dec 13, 2009 at 2:42 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
>> The Board has in the past condemned "balkanization" of community, and my
>> take on this situation is exactly that.
>>
>> This is not "yet another web framework", which often brought forward as
>> examples that the ASF encourages competition within. Those typically have a
>> different "angle", "approach" or "metaphor", something making each very
>> different beasts. But in this case we are talking about "the same spec".
>> There is no real distinguishing features and huge overlap of commonality.
>>
>> I think this is a NIH-syndrome in play, in the best case "oh we have the
>> code working already" and the worst case "we don't like to collaborate with
>> them", and there is reason to think that that goes for both sides of the
>> fence.
>>
>> I want to see Chemistry capable to absorb such contribution and collaborate
>> heavily to bring such codebase in.
>> And I want to see the people of the OpenCMIS proposal to show that they
>> indeed can work with others.
>>
>> Exactly how the merged community goes about with the technical integration
>> is its own business, but I am worried that the new codebase will not receive
>> the welcome I hope, the Chemistry base will dominate, and the OpenCMIS
>> proposer get fed up and leaves. Important Mentors understand the risks here,
>> and keep eyes extra open for attrition, domination and forceful
>> consensus-seeking.
>>
>
> I agree with those sentiments.
>
>> I think discussion should continue on Chemistry dev@ list. If agreement
>> can't be reached there, then I am NOT in favor of incubating OpenCMIS
>> separately and will vote -1 to such proposal. I will also form myself an
>> opinion of how well Chemistry is trying to collaborate, and it may improve
>> or deteriorate its status with me.
>>
>
> I don't think it would be helpful for either OpenCMIS or Chemistry for
> the IPMC to just unilaterally dictate that "it must be done in
> Chemistry". IMHO that would make for too unlevel a playing field which
> could adversely impact any attempts to collaborate (or even just get
> stuff done). That works both ways - it would be hard for OpenCMIS
> being forced to be part of Chemistry, but also potentially hard for
> Chemistry to all of a sudden have a significant number of new
> committers forced upon them and upsetting the status quo.
>
> The Incubator has always been very clear about having a very low bar
> of entry to incubation so IMHO it shouldn't matter that the incoming
> podling is doing the same spec as another poddling, thats something
> that could be worked out during incubation. So I'd +1 accepting this
> new OpenCMIS proposal (if they can find champion and mentors). If
> we're really concerned about having multiple spec impls then we can
> make this a graduation requirement - neither Chemistry or OpenCMIS
> graduate until they've both worked out how to exist together.
>
>
>> This can become an excellent opportunity for all involved to show off their
>> ApacheWay skills
>>
>
> +1!
>
>> -- Niclas
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by ant elder <an...@gmail.com>.
On Sun, Dec 13, 2009 at 2:42 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> The Board has in the past condemned "balkanization" of community, and my
> take on this situation is exactly that.
>
> This is not "yet another web framework", which often brought forward as
> examples that the ASF encourages competition within. Those typically have a
> different "angle", "approach" or "metaphor", something making each very
> different beasts. But in this case we are talking about "the same spec".
> There is no real distinguishing features and huge overlap of commonality.
>
> I think this is a NIH-syndrome in play, in the best case "oh we have the
> code working already" and the worst case "we don't like to collaborate with
> them", and there is reason to think that that goes for both sides of the
> fence.
>
> I want to see Chemistry capable to absorb such contribution and collaborate
> heavily to bring such codebase in.
> And I want to see the people of the OpenCMIS proposal to show that they
> indeed can work with others.
>
> Exactly how the merged community goes about with the technical integration
> is its own business, but I am worried that the new codebase will not receive
> the welcome I hope, the Chemistry base will dominate, and the OpenCMIS
> proposer get fed up and leaves. Important Mentors understand the risks here,
> and keep eyes extra open for attrition, domination and forceful
> consensus-seeking.
>
I agree with those sentiments.
> I think discussion should continue on Chemistry dev@ list. If agreement
> can't be reached there, then I am NOT in favor of incubating OpenCMIS
> separately and will vote -1 to such proposal. I will also form myself an
> opinion of how well Chemistry is trying to collaborate, and it may improve
> or deteriorate its status with me.
>
I don't think it would be helpful for either OpenCMIS or Chemistry for
the IPMC to just unilaterally dictate that "it must be done in
Chemistry". IMHO that would make for too unlevel a playing field which
could adversely impact any attempts to collaborate (or even just get
stuff done). That works both ways - it would be hard for OpenCMIS
being forced to be part of Chemistry, but also potentially hard for
Chemistry to all of a sudden have a significant number of new
committers forced upon them and upsetting the status quo.
The Incubator has always been very clear about having a very low bar
of entry to incubation so IMHO it shouldn't matter that the incoming
podling is doing the same spec as another poddling, thats something
that could be worked out during incubation. So I'd +1 accepting this
new OpenCMIS proposal (if they can find champion and mentors). If
we're really concerned about having multiple spec impls then we can
make this a graduation requirement - neither Chemistry or OpenCMIS
graduate until they've both worked out how to exist together.
> This can become an excellent opportunity for all involved to show off their
> ApacheWay skills
>
+1!
> -- Niclas
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Niclas Hedhman <ni...@hedhman.org>.
The Board has in the past condemned "balkanization" of community, and my
take on this situation is exactly that.
This is not "yet another web framework", which often brought forward as
examples that the ASF encourages competition within. Those typically have a
different "angle", "approach" or "metaphor", something making each very
different beasts. But in this case we are talking about "the same spec".
There is no real distinguishing features and huge overlap of commonality.
I think this is a NIH-syndrome in play, in the best case "oh we have the
code working already" and the worst case "we don't like to collaborate with
them", and there is reason to think that that goes for both sides of the
fence.
I want to see Chemistry capable to absorb such contribution and collaborate
heavily to bring such codebase in.
And I want to see the people of the OpenCMIS proposal to show that they
indeed can work with others.
Exactly how the merged community goes about with the technical integration
is its own business, but I am worried that the new codebase will not receive
the welcome I hope, the Chemistry base will dominate, and the OpenCMIS
proposer get fed up and leaves. Important Mentors understand the risks here,
and keep eyes extra open for attrition, domination and forceful
consensus-seeking.
I think discussion should continue on Chemistry dev@ list. If agreement
can't be reached there, then I am NOT in favor of incubating OpenCMIS
separately and will vote -1 to such proposal. I will also form myself an
opinion of how well Chemistry is trying to collaborate, and it may improve
or deteriorate its status with me.
This can become an excellent opportunity for all involved to show off their
ApacheWay skills
-- Niclas
On 13 Dec 2009 09:47, "Emmanuel LŽcharny" <el...@gmail.com> wrote:
Joe Schaefer a écrit :
> <snip/>
>
> >> >> I see where Joe is going to with his "let both project get in and
> let's see which one will su...
>
I must admit that it's human nature, but I think - but I'm probably
optimistic - that people working on an apache project should overcome this
reluctance. In this very case, as Chemistry has entered the incubator more
than 6 months ago, I can understand that 'merging' with OpenCMIS would slow
down the process, and OTOH, OpenCMIS may not like the idea to be seen as a
sub-project... But this is the Incubator, the perfect place yo work out such
problems. My fear is that by accepting two separate projects, one may die
(or even both), because of the lack of community... It seems less likely if
both project work out a common solution, IMHO.
Collaboration does not kill good ideas...
--------------------------------------------------------------------- To
unsubscribe, e-mail: g...
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability
Services (CMIS)
Posted by Michael Wechner <mi...@wyona.com>.
Stefane Fermigier wrote:
>
> On Dec 12, 2009, at 1:36 PM, Michael Wechner wrote:
>
>> Stefane Fermigier schrieb:
>>> OK, I personally believe this is in contradiction with the first
>>> commandment of the Apache Way:
>>>
>>> "*Community over Code* is a frequent saying that exemplifies ASF
>>> projects. Community uses Openness and Merit, expressed through
>>> Collaborative and Consensus driven work, to build lasting projects
>>> that use a Pragmatic License. While a diverse community is a
>>> requirement for every ASF project, we also expect people to
>>> contribute as Individuals, and wear appropriate Hats."
>>
>> I cannot see any contradiction. Can you explain where exactly you see
>> the contradiction?
>
> As I understand it, the Apache Way means that building consensus has
> more value than a code base that can be donated but can't be modified
> because, well, there are good reasons not to do it.
are you refering to the OpenCMIS code? If so, then please say so and
give the OpenCMIS folks a change to prove different.
>
>>> -> Let our Apache Foundation overlords decide.
>>
>> who are you refering to?
>
> I'm not familiar with the process, but I understand that some people
> are going to be responsible for deciding who will graduate and who won't.
maybe you want to take a look at
http://incubator.apache.org/guides/graduation.html
since I guess this also matters to Chemistry ;-)
>
>>> I still think that at least there should be common code (ex:
>>> constants, as suggested by Jukka) and I hope that this will the
>>> case, in any case.
>>
>> Maybe you want to go one step towards OpenCMIS and make a concrete
>> suggestion what you think could be shared and I am quite certain
>> the OpenCMIS guys will also make a step towards Chemistry as well
>> .... and I am confident collaboration will happen, but yes somebody has
>> to make a first step and maybe it is even an advantage to take this
>> first step ;-)
>
> I think suggestions have already been made.
are you refering to Jukka's suggestions? Of which suggestions exactly?
@OpenCMIS folks: What is your point of view re Jukka's suggestions?
Cheers
Michael
>
> S.
>
> --
> Stefane Fermigier, Founder and Chairman, Nuxeo
> Open Source, Java EE based, Enterprise Content Management (ECM)
> Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
> New: follow me on Twitter: http://twitter.com/sfermigier
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability
Services (CMIS)
Posted by Michael Wechner <mi...@wyona.com>.
Stefane Fermigier wrote:
>
> On Dec 12, 2009, at 1:36 PM, Michael Wechner wrote:
>
>> Stefane Fermigier schrieb:
>>> OK, I personally believe this is in contradiction with the first
>>> commandment of the Apache Way:
>>>
>>> "*Community over Code* is a frequent saying that exemplifies ASF
>>> projects. Community uses Openness and Merit, expressed through
>>> Collaborative and Consensus driven work, to build lasting projects
>>> that use a Pragmatic License. While a diverse community is a
>>> requirement for every ASF project, we also expect people to
>>> contribute as Individuals, and wear appropriate Hats."
>>
>> I cannot see any contradiction. Can you explain where exactly you see
>> the contradiction?
>
> As I understand it, the Apache Way means that building consensus has
> more value than a code base that can be donated but can't be modified
> because, well, there are good reasons not to do it.
are you refering to the OpenCMIS code? If so, then please say so and
give the OpenCMIS folks a change to prove different.
>
>>> -> Let our Apache Foundation overlords decide.
>>
>> who are you refering to?
>
> I'm not familiar with the process, but I understand that some people
> are going to be responsible for deciding who will graduate and who won't.
maybe you want to take a look at
http://incubator.apache.org/guides/graduation.html
since I guess this also matters to Chemistry ;-)
>
>>> I still think that at least there should be common code (ex:
>>> constants, as suggested by Jukka) and I hope that this will the
>>> case, in any case.
>>
>> Maybe you want to go one step towards OpenCMIS and make a concrete
>> suggestion what you think could be shared and I am quite certain
>> the OpenCMIS guys will also make a step towards Chemistry as well
>> .... and I am confident collaboration will happen, but yes somebody has
>> to make a first step and maybe it is even an advantage to take this
>> first step ;-)
>
> I think suggestions have already been made.
are you refering to Jukka's suggestions? Of which suggestions exactly?
@OpenCMIS folks: What is your point of view re Jukka's suggestions?
Cheers
Michael
>
> S.
>
> --
> Stefane Fermigier, Founder and Chairman, Nuxeo
> Open Source, Java EE based, Enterprise Content Management (ECM)
> Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
> New: follow me on Twitter: http://twitter.com/sfermigier
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Stefane Fermigier <sf...@nuxeo.com>.
On Dec 12, 2009, at 1:36 PM, Michael Wechner wrote:
> Stefane Fermigier schrieb:
>> OK, I personally believe this is in contradiction with the first
>> commandment of the Apache Way:
>>
>> "*Community over Code* is a frequent saying that exemplifies ASF
>> projects. Community uses Openness and Merit, expressed through
>> Collaborative and Consensus driven work, to build lasting projects
>> that use a Pragmatic License. While a diverse community is a
>> requirement for every ASF project, we also expect people to
>> contribute as Individuals, and wear appropriate Hats."
>
> I cannot see any contradiction. Can you explain where exactly you
> see the contradiction?
As I understand it, the Apache Way means that building consensus has
more value than a code base that can be donated but can't be modified
because, well, there are good reasons not to do it.
>> -> Let our Apache Foundation overlords decide.
>
> who are you refering to?
I'm not familiar with the process, but I understand that some people
are going to be responsible for deciding who will graduate and who
won't.
>> I still think that at least there should be common code (ex:
>> constants, as suggested by Jukka) and I hope that this will the
>> case, in any case.
>
> Maybe you want to go one step towards OpenCMIS and make a concrete
> suggestion what you think could be shared and I am quite certain
> the OpenCMIS guys will also make a step towards Chemistry as
> well .... and I am confident collaboration will happen, but yes
> somebody has
> to make a first step and maybe it is even an advantage to take this
> first step ;-)
I think suggestions have already been made.
S.
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
New: follow me on Twitter: http://twitter.com/sfermigier
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability
Services (CMIS)
Posted by Emmanuel Lcharny <el...@gmail.com>.
Joe Schaefer a écrit :
> <snip/>
>> I see where Joe is going to with his "let both project get in and let's see
>> which one will survive", I can't help but thinking that beside the rules, there
>> is a spirit which is way more important.
>>
>> At least, let's try...
>>
>
> The way I see it the purpose of a proposal is to attract mentors to the proposal.
> Given that Chemistry is already here, and contains lots of people who know how
> to build communities around the code, I can understand the reluctance to support
> a competing effort by some people.
I must admit that it's human nature, but I think - but I'm probably
optimistic - that people working on an apache project should overcome
this reluctance. In this very case, as Chemistry has entered the
incubator more than 6 months ago, I can understand that 'merging' with
OpenCMIS would slow down the process, and OTOH, OpenCMIS may not like
the idea to be seen as a sub-project... But this is the Incubator, the
perfect place yo work out such problems. My fear is that by accepting
two separate projects, one may die (or even both), because of the lack
of community... It seems less likely if both project work out a common
solution, IMHO.
Collaboration does not kill good ideas...
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Emmanuel Lcharny <el...@gmail.com>
> To: general@incubator.apache.org
> Sent: Sat, December 12, 2009 7:32:53 PM
> Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
>
> Michael Wechner a écrit :
> > Emmanuel Lcharny wrote:
> >> Michael Wechner a écrit :
> >>> Stefane Fermigier schrieb:
> >>>> OK, I personally believe this is in contradiction with the first
> commandment of the Apache Way:
> >>>>
> >>>> "*Community over Code* is a frequent saying that exemplifies ASF projects.
> Community uses Openness and Merit, expressed through Collaborative and Consensus
> driven work, to build lasting projects that use a Pragmatic License. While a
> diverse community is a requirement for every ASF project, we also expect people
> to contribute as Individuals, and wear appropriate Hats."
> >>>
> >>> I cannot see any contradiction. Can you explain where exactly you see the
> contradiction?
> >> Hi,
> >>
> >> I just grab the description of both projects :
> >>
> >> "OpenCMIS will deliver a Java implementation of the OASIS CMIS
> specification."
> >>
> >> "Apache Chemistry is a generic Java language implementation of the upcoming
> OASIS CMIS specification. "
> >>
> >> I barely see how two communities working on two projects with the very same
> target can't collaborate and form the best possible community to fulfill this
> target, leveraging the great people from both of the current project...
> >>
> >> This is where I see a contradiction : it seems like there is some divergence
> on the technical side, which is not really the Incubator concern. What is
> important to us is that a community is built, because it's the guarantee for a
> long term existence for the project. We don't have the resources and time to
> setup a darwinian process here :)
> >
> > I am not sure what exactly you mean with "we", but I would argue that the CMS
> community out there is rather large and has enough
> > potential to provide contributors for both projects.
> >
> > It's up to each incubator project itself to build a healthy community and
> AFAIK these rules are clear and in particular what it takes to leave the
> incubator.
> > So either a project will make it or not. I am assuming this is what the
> incubator is good for, right?
>
> Would the Incubator be a place where projects enter and try to develop and
> succeed per their technical merit only, I would agree. But it involves people
> with a limited timeframe (mentors, champion, PMC members), and I feel that it's
> a bit a waste to see two projects trying to implement the exact same spec unable
> to collaborate. I mean, both teams most certainly have their own merit, I won't
> argue this point, but at some point a bit less ego and a bit more collaboration
> will generate a better result.
>
> I see where Joe is going to with his "let both project get in and let's see
> which one will survive", I can't help but thinking that beside the rules, there
> is a spirit which is way more important.
>
> At least, let's try...
The way I see it the purpose of a proposal is to attract mentors to the proposal.
Given that Chemistry is already here, and contains lots of people who know how
to build communities around the code, I can understand the reluctance to support
a competing effort by some people. But Apache is a big organization, certainly
big enough for two entries into the CMIS market if things work out that way. But
I am always skeptical about a project with closed-source origins without a decent
contingent of Apache people already involved.
Let me also make it clear that I have no interest in either project, so my remarks
are meant to be taken as coming from a distance.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability
Services (CMIS)
Posted by Emmanuel Lcharny <el...@gmail.com>.
Michael Wechner a écrit :
> Emmanuel Lcharny wrote:
>> Michael Wechner a écrit :
>>> Stefane Fermigier schrieb:
>>>> OK, I personally believe this is in contradiction with the first
>>>> commandment of the Apache Way:
>>>>
>>>> "*Community over Code* is a frequent saying that exemplifies ASF
>>>> projects. Community uses Openness and Merit, expressed through
>>>> Collaborative and Consensus driven work, to build lasting projects
>>>> that use a Pragmatic License. While a diverse community is a
>>>> requirement for every ASF project, we also expect people to
>>>> contribute as Individuals, and wear appropriate Hats."
>>>
>>> I cannot see any contradiction. Can you explain where exactly you
>>> see the contradiction?
>> Hi,
>>
>> I just grab the description of both projects :
>>
>> "OpenCMIS will deliver a Java implementation of the OASIS CMIS
>> specification."
>>
>> "Apache Chemistry is a generic Java language implementation of the
>> upcoming OASIS CMIS specification. "
>>
>> I barely see how two communities working on two projects with the
>> very same target can't collaborate and form the best possible
>> community to fulfill this target, leveraging the great people from
>> both of the current project...
>>
>> This is where I see a contradiction : it seems like there is some
>> divergence on the technical side, which is not really the Incubator
>> concern. What is important to us is that a community is built,
>> because it's the guarantee for a long term existence for the project.
>> We don't have the resources and time to setup a darwinian process
>> here :)
>
> I am not sure what exactly you mean with "we", but I would argue that
> the CMS community out there is rather large and has enough
> potential to provide contributors for both projects.
>
> It's up to each incubator project itself to build a healthy community
> and AFAIK these rules are clear and in particular what it takes to
> leave the incubator.
> So either a project will make it or not. I am assuming this is what
> the incubator is good for, right?
Would the Incubator be a place where projects enter and try to develop
and succeed per their technical merit only, I would agree. But it
involves people with a limited timeframe (mentors, champion, PMC
members), and I feel that it's a bit a waste to see two projects trying
to implement the exact same spec unable to collaborate. I mean, both
teams most certainly have their own merit, I won't argue this point, but
at some point a bit less ego and a bit more collaboration will generate
a better result.
I see where Joe is going to with his "let both project get in and let's
see which one will survive", I can't help but thinking that beside the
rules, there is a spirit which is way more important.
At least, let's try...
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability
Services (CMIS)
Posted by Michael Wechner <mi...@wyona.com>.
Emmanuel Lcharny wrote:
> Michael Wechner a écrit :
>> Stefane Fermigier schrieb:
>>> OK, I personally believe this is in contradiction with the first
>>> commandment of the Apache Way:
>>>
>>> "*Community over Code* is a frequent saying that exemplifies ASF
>>> projects. Community uses Openness and Merit, expressed through
>>> Collaborative and Consensus driven work, to build lasting projects
>>> that use a Pragmatic License. While a diverse community is a
>>> requirement for every ASF project, we also expect people to
>>> contribute as Individuals, and wear appropriate Hats."
>>
>> I cannot see any contradiction. Can you explain where exactly you see
>> the contradiction?
> Hi,
>
> I just grab the description of both projects :
>
> "OpenCMIS will deliver a Java implementation of the OASIS CMIS
> specification."
>
> "Apache Chemistry is a generic Java language implementation of the
> upcoming OASIS CMIS specification. "
>
> I barely see how two communities working on two projects with the very
> same target can't collaborate and form the best possible community to
> fulfill this target, leveraging the great people from both of the
> current project...
>
> This is where I see a contradiction : it seems like there is some
> divergence on the technical side, which is not really the Incubator
> concern. What is important to us is that a community is built, because
> it's the guarantee for a long term existence for the project. We don't
> have the resources and time to setup a darwinian process here :)
I am not sure what exactly you mean with "we", but I would argue that
the CMS community out there is rather large and has enough
potential to provide contributors for both projects.
It's up to each incubator project itself to build a healthy community
and AFAIK these rules are clear and in particular what it takes to leave
the incubator.
So either a project will make it or not. I am assuming this is what the
incubator is good for, right?
Cheers
Michael
>
> my 2 cts ...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability
Services (CMIS)
Posted by Emmanuel Lcharny <el...@gmail.com>.
Michael Wechner a écrit :
> Stefane Fermigier schrieb:
>> OK, I personally believe this is in contradiction with the first
>> commandment of the Apache Way:
>>
>> "*Community over Code* is a frequent saying that exemplifies ASF
>> projects. Community uses Openness and Merit, expressed through
>> Collaborative and Consensus driven work, to build lasting projects
>> that use a Pragmatic License. While a diverse community is a
>> requirement for every ASF project, we also expect people to
>> contribute as Individuals, and wear appropriate Hats."
>
> I cannot see any contradiction. Can you explain where exactly you see
> the contradiction?
Hi,
I just grab the description of both projects :
"OpenCMIS will deliver a Java implementation of the OASIS CMIS
specification."
"Apache Chemistry is a generic Java language implementation of the
upcoming OASIS CMIS specification. "
I barely see how two communities working on two projects with the very
same target can't collaborate and form the best possible community to
fulfill this target, leveraging the great people from both of the
current project...
This is where I see a contradiction : it seems like there is some
divergence on the technical side, which is not really the Incubator
concern. What is important to us is that a community is built, because
it's the guarantee for a long term existence for the project. We don't
have the resources and time to setup a darwinian process here :)
my 2 cts ...
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Stefane Fermigier <sf...@nuxeo.com>.
On Dec 12, 2009, at 1:36 PM, Michael Wechner wrote:
> Stefane Fermigier schrieb:
>> OK, I personally believe this is in contradiction with the first
>> commandment of the Apache Way:
>>
>> "*Community over Code* is a frequent saying that exemplifies ASF
>> projects. Community uses Openness and Merit, expressed through
>> Collaborative and Consensus driven work, to build lasting projects
>> that use a Pragmatic License. While a diverse community is a
>> requirement for every ASF project, we also expect people to
>> contribute as Individuals, and wear appropriate Hats."
>
> I cannot see any contradiction. Can you explain where exactly you
> see the contradiction?
As I understand it, the Apache Way means that building consensus has
more value than a code base that can be donated but can't be modified
because, well, there are good reasons not to do it.
>> -> Let our Apache Foundation overlords decide.
>
> who are you refering to?
I'm not familiar with the process, but I understand that some people
are going to be responsible for deciding who will graduate and who
won't.
>> I still think that at least there should be common code (ex:
>> constants, as suggested by Jukka) and I hope that this will the
>> case, in any case.
>
> Maybe you want to go one step towards OpenCMIS and make a concrete
> suggestion what you think could be shared and I am quite certain
> the OpenCMIS guys will also make a step towards Chemistry as
> well .... and I am confident collaboration will happen, but yes
> somebody has
> to make a first step and maybe it is even an advantage to take this
> first step ;-)
I think suggestions have already been made.
S.
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
New: follow me on Twitter: http://twitter.com/sfermigier
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability
Services (CMIS)
Posted by Michael Wechner <mi...@wyona.com>.
Stefane Fermigier schrieb:
> OK, I personally believe this is in contradiction with the first
> commandment of the Apache Way:
>
> "*Community over Code* is a frequent saying that exemplifies ASF
> projects. Community uses Openness and Merit, expressed through
> Collaborative and Consensus driven work, to build lasting projects
> that use a Pragmatic License. While a diverse community is a
> requirement for every ASF project, we also expect people to contribute
> as Individuals, and wear appropriate Hats."
I cannot see any contradiction. Can you explain where exactly you see
the contradiction?
>
> -> Let our Apache Foundation overlords decide.
who are you refering to?
>
> I still think that at least there should be common code (ex:
> constants, as suggested by Jukka) and I hope that this will the case,
> in any case.
Maybe you want to go one step towards OpenCMIS and make a concrete
suggestion what you think could be shared and I am quite certain
the OpenCMIS guys will also make a step towards Chemistry as well ....
and I am confident collaboration will happen, but yes somebody has
to make a first step and maybe it is even an advantage to take this
first step ;-)
Cheers
Michael
>
> S.
>
> On Dec 11, 2009, at 11:18 PM, Michael Wechner wrote:
>
>> Florian Müller wrote:
>>> Well, here is a citation from
>>> http://www.apache.org/foundation/how-it-works.html (section "The
>>> Foundation Incubator"):
>>>
>>> "It must be noted that the incubator (just like the board) does not
>>> perform filtering on the basis of technical issues. This is because
>>> the foundation respects and suggests variety of technical
>>> approaches. It doesn't fear innovation or even internal
>>> confrontation between projects which overlap in functionality."
>>>
>>
>> right and as long as OpenCMIS fulfills the requirements of the
>> incubator I don't see any reason why there shouldn't be two projects
>> of the same topic.
>>
>> I also do not see any reason why OpenCMIS should be a sub-project of
>> Chemistry.
>> Give it a chance of its own within the current rules of the incubator
>> and it will either work or not.
>> If it works, then graduate, if not, then remove it.
>>
>> Or am I missing something which violates any current rule of the
>> incubator?
>>
>> Cheers
>>
>> Michael
>>> Florian
>>>
>>> -----Original Message-----
>>> From: Stefane Fermigier [mailto:sf@nuxeo.com] Sent: Friday, December
>>> 11, 2009 7:46 PM
>>> To: chemistry-dev@incubator.apache.org
>>> Cc: Incubator-General
>>> Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
>>> Interoperability Services (CMIS)
>>>
>>>
>>> On Dec 11, 2009, at 7:10 PM, Florian Müller wrote:
>>>
>>>> Chemistry uses Abdera to communicate with the server while
>>>> OpenCMIS is based on JAX-B and some CMIS specific XML coding.
>>>>
>>>
>>> I've been personally asking myself recently wether it would be
>>> feasible to drop Abdera in favor of JAXB in Chemistry, so IMHO it's
>>> something that should be discussed together and not a division line
>>> for us.
>>>
>>>
>>>> There is a lot of code sharing between the AtomPub and the Web
>>>> Services binding. (I couldn't find a Web Services client in Chemistry.
>>>>
>>>
>>> It would be great if you could contribute one.
>>>
>>>
>>>> Here we are with a working code base that we cannot give up and
>>>> that we will maintain in the future for obvious reasons. Our idea
>>>> was to make it Open Source and let others benefit from our work.
>>>> Apache seemed to be the right place - at least three days ago.
>>>>
>>>
>>> OK, I'm new to this Apache thing, but I don't believe this is the
>>> Apache Way. See: http://theapacheway.com/ or
>>> http://www.slideshare.net/jaaronfarr/the-apache-way-hk-sfd-2009
>>>
>>> S.
>>>
>>> --
>>> Stefane Fermigier, Founder and Chairman, Nuxeo
>>> Open Source, Java EE based, Enterprise Content Management (ECM)
>>> Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
>>> New: follow me on Twitter: http://twitter.com/sfermigier
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
>
> --
> Stefane Fermigier, Founder and Chairman, Nuxeo
> Open Source, Java EE based, Enterprise Content Management (ECM)
> Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
> New: follow me on Twitter: http://twitter.com/sfermigier
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Sat, Dec 12, 2009 at 10:27 AM, Stefane Fermigier <sf...@nuxeo.com> wrote:
> OK, I personally believe this is in contradiction with the first commandment
> of the Apache Way:
>
> "*Community over Code* is a frequent saying that exemplifies ASF projects.
> Community uses Openness and Merit, expressed through Collaborative and
> Consensus driven work, to build lasting projects that use a Pragmatic
> License. While a diverse community is a requirement for every ASF project,
> we also expect people to contribute as Individuals, and wear appropriate
> Hats."
>
> -> Let our Apache Foundation overlords decide...
Too bad...there are no overlords here ;-)
Some of us are speaking as members of the Incubator PMC, having seen a
few podlings succeed or fail, and trying to ensure success of at least
one (or maybe two if that's needed) CMIS podlings. But in the end it's
a decision of the whole Incubator PMC, which I imagine is heavily
influenced by having a champion and a few mentors take care of the
podling.
In my case, the lukewarm welcome to OpenCMIS is mostly due to the fact
that nothing was discussed with Chemistry before making the proposal.
To me that feels like doing things behind the Chemistry team's back,
which I don't like. Hopefully that's being sorted out with the current
discussions.
> ...I still think that at least there should be common code (ex: constants, as
> suggested by Jukka) and I hope that this will the case, in any case....
Sure - that's also possible by sharing code, for example by giving
write access to both Chemistry and OpemCMIS committers to some part of
each other's code repository. I'd much prefer having a single project,
as I said before, but two projects that collaborate on common parts
(like a test suite I imagine) can work as well.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability
Services (CMIS)
Posted by Michael Wechner <mi...@wyona.com>.
Stefane Fermigier schrieb:
> OK, I personally believe this is in contradiction with the first
> commandment of the Apache Way:
>
> "*Community over Code* is a frequent saying that exemplifies ASF
> projects. Community uses Openness and Merit, expressed through
> Collaborative and Consensus driven work, to build lasting projects
> that use a Pragmatic License. While a diverse community is a
> requirement for every ASF project, we also expect people to contribute
> as Individuals, and wear appropriate Hats."
I cannot see any contradiction. Can you explain where exactly you see
the contradiction?
>
> -> Let our Apache Foundation overlords decide.
who are you refering to?
>
> I still think that at least there should be common code (ex:
> constants, as suggested by Jukka) and I hope that this will the case,
> in any case.
Maybe you want to go one step towards OpenCMIS and make a concrete
suggestion what you think could be shared and I am quite certain
the OpenCMIS guys will also make a step towards Chemistry as well ....
and I am confident collaboration will happen, but yes somebody has
to make a first step and maybe it is even an advantage to take this
first step ;-)
Cheers
Michael
>
> S.
>
> On Dec 11, 2009, at 11:18 PM, Michael Wechner wrote:
>
>> Florian Müller wrote:
>>> Well, here is a citation from
>>> http://www.apache.org/foundation/how-it-works.html (section "The
>>> Foundation Incubator"):
>>>
>>> "It must be noted that the incubator (just like the board) does not
>>> perform filtering on the basis of technical issues. This is because
>>> the foundation respects and suggests variety of technical
>>> approaches. It doesn't fear innovation or even internal
>>> confrontation between projects which overlap in functionality."
>>>
>>
>> right and as long as OpenCMIS fulfills the requirements of the
>> incubator I don't see any reason why there shouldn't be two projects
>> of the same topic.
>>
>> I also do not see any reason why OpenCMIS should be a sub-project of
>> Chemistry.
>> Give it a chance of its own within the current rules of the incubator
>> and it will either work or not.
>> If it works, then graduate, if not, then remove it.
>>
>> Or am I missing something which violates any current rule of the
>> incubator?
>>
>> Cheers
>>
>> Michael
>>> Florian
>>>
>>> -----Original Message-----
>>> From: Stefane Fermigier [mailto:sf@nuxeo.com] Sent: Friday, December
>>> 11, 2009 7:46 PM
>>> To: chemistry-dev@incubator.apache.org
>>> Cc: Incubator-General
>>> Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
>>> Interoperability Services (CMIS)
>>>
>>>
>>> On Dec 11, 2009, at 7:10 PM, Florian Müller wrote:
>>>
>>>> Chemistry uses Abdera to communicate with the server while
>>>> OpenCMIS is based on JAX-B and some CMIS specific XML coding.
>>>>
>>>
>>> I've been personally asking myself recently wether it would be
>>> feasible to drop Abdera in favor of JAXB in Chemistry, so IMHO it's
>>> something that should be discussed together and not a division line
>>> for us.
>>>
>>>
>>>> There is a lot of code sharing between the AtomPub and the Web
>>>> Services binding. (I couldn't find a Web Services client in Chemistry.
>>>>
>>>
>>> It would be great if you could contribute one.
>>>
>>>
>>>> Here we are with a working code base that we cannot give up and
>>>> that we will maintain in the future for obvious reasons. Our idea
>>>> was to make it Open Source and let others benefit from our work.
>>>> Apache seemed to be the right place - at least three days ago.
>>>>
>>>
>>> OK, I'm new to this Apache thing, but I don't believe this is the
>>> Apache Way. See: http://theapacheway.com/ or
>>> http://www.slideshare.net/jaaronfarr/the-apache-way-hk-sfd-2009
>>>
>>> S.
>>>
>>> --
>>> Stefane Fermigier, Founder and Chairman, Nuxeo
>>> Open Source, Java EE based, Enterprise Content Management (ECM)
>>> Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
>>> New: follow me on Twitter: http://twitter.com/sfermigier
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>>
>
> --
> Stefane Fermigier, Founder and Chairman, Nuxeo
> Open Source, Java EE based, Enterprise Content Management (ECM)
> Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
> New: follow me on Twitter: http://twitter.com/sfermigier
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Sat, Dec 12, 2009 at 10:27 AM, Stefane Fermigier <sf...@nuxeo.com> wrote:
> OK, I personally believe this is in contradiction with the first commandment
> of the Apache Way:
>
> "*Community over Code* is a frequent saying that exemplifies ASF projects.
> Community uses Openness and Merit, expressed through Collaborative and
> Consensus driven work, to build lasting projects that use a Pragmatic
> License. While a diverse community is a requirement for every ASF project,
> we also expect people to contribute as Individuals, and wear appropriate
> Hats."
>
> -> Let our Apache Foundation overlords decide...
Too bad...there are no overlords here ;-)
Some of us are speaking as members of the Incubator PMC, having seen a
few podlings succeed or fail, and trying to ensure success of at least
one (or maybe two if that's needed) CMIS podlings. But in the end it's
a decision of the whole Incubator PMC, which I imagine is heavily
influenced by having a champion and a few mentors take care of the
podling.
In my case, the lukewarm welcome to OpenCMIS is mostly due to the fact
that nothing was discussed with Chemistry before making the proposal.
To me that feels like doing things behind the Chemistry team's back,
which I don't like. Hopefully that's being sorted out with the current
discussions.
> ...I still think that at least there should be common code (ex: constants, as
> suggested by Jukka) and I hope that this will the case, in any case....
Sure - that's also possible by sharing code, for example by giving
write access to both Chemistry and OpemCMIS committers to some part of
each other's code repository. I'd much prefer having a single project,
as I said before, but two projects that collaborate on common parts
(like a test suite I imagine) can work as well.
-Bertrand
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Stefane Fermigier <sf...@nuxeo.com>.
OK, I personally believe this is in contradiction with the first
commandment of the Apache Way:
"*Community over Code* is a frequent saying that exemplifies ASF
projects. Community uses Openness and Merit, expressed through
Collaborative and Consensus driven work, to build lasting projects
that use a Pragmatic License. While a diverse community is a
requirement for every ASF project, we also expect people to contribute
as Individuals, and wear appropriate Hats."
-> Let our Apache Foundation overlords decide.
I still think that at least there should be common code (ex:
constants, as suggested by Jukka) and I hope that this will the case,
in any case.
S.
On Dec 11, 2009, at 11:18 PM, Michael Wechner wrote:
> Florian Müller wrote:
>> Well, here is a citation from http://www.apache.org/foundation/how-it-works.html
>> (section "The Foundation Incubator"):
>>
>> "It must be noted that the incubator (just like the board) does not
>> perform filtering on the basis of technical issues. This is because
>> the foundation respects and suggests variety of technical
>> approaches. It doesn't fear innovation or even internal
>> confrontation between projects which overlap in functionality."
>>
>
> right and as long as OpenCMIS fulfills the requirements of the
> incubator I don't see any reason why there shouldn't be two projects
> of the same topic.
>
> I also do not see any reason why OpenCMIS should be a sub-project of
> Chemistry.
> Give it a chance of its own within the current rules of the
> incubator and it will either work or not.
> If it works, then graduate, if not, then remove it.
>
> Or am I missing something which violates any current rule of the
> incubator?
>
> Cheers
>
> Michael
>> Florian
>>
>> -----Original Message-----
>> From: Stefane Fermigier [mailto:sf@nuxeo.com] Sent: Friday,
>> December 11, 2009 7:46 PM
>> To: chemistry-dev@incubator.apache.org
>> Cc: Incubator-General
>> Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
>> Interoperability Services (CMIS)
>>
>>
>> On Dec 11, 2009, at 7:10 PM, Florian Müller wrote:
>>
>>> Chemistry uses Abdera to communicate with the server while
>>> OpenCMIS is based on JAX-B and some CMIS specific XML coding.
>>>
>>
>> I've been personally asking myself recently wether it would be
>> feasible to drop Abdera in favor of JAXB in Chemistry, so IMHO
>> it's something that should be discussed together and not a
>> division line for us.
>>
>>
>>> There is a lot of code sharing between the AtomPub and the Web
>>> Services binding. (I couldn't find a Web Services client in
>>> Chemistry.
>>>
>>
>> It would be great if you could contribute one.
>>
>>
>>> Here we are with a working code base that we cannot give up and
>>> that we will maintain in the future for obvious reasons. Our idea
>>> was to make it Open Source and let others benefit from our work.
>>> Apache seemed to be the right place - at least three days ago.
>>>
>>
>> OK, I'm new to this Apache thing, but I don't believe this is the
>> Apache Way. See: http://theapacheway.com/ or http://www.slideshare.net/jaaronfarr/the-apache-way-hk-sfd-2009
>>
>> S.
>>
>> --
>> Stefane Fermigier, Founder and Chairman, Nuxeo
>> Open Source, Java EE based, Enterprise Content Management (ECM)
>> Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
>> New: follow me on Twitter: http://twitter.com/sfermigier
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
New: follow me on Twitter: http://twitter.com/sfermigier
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Stefane Fermigier <sf...@nuxeo.com>.
OK, I personally believe this is in contradiction with the first
commandment of the Apache Way:
"*Community over Code* is a frequent saying that exemplifies ASF
projects. Community uses Openness and Merit, expressed through
Collaborative and Consensus driven work, to build lasting projects
that use a Pragmatic License. While a diverse community is a
requirement for every ASF project, we also expect people to contribute
as Individuals, and wear appropriate Hats."
-> Let our Apache Foundation overlords decide.
I still think that at least there should be common code (ex:
constants, as suggested by Jukka) and I hope that this will the case,
in any case.
S.
On Dec 11, 2009, at 11:18 PM, Michael Wechner wrote:
> Florian Müller wrote:
>> Well, here is a citation from http://www.apache.org/foundation/how-it-works.html
>> (section "The Foundation Incubator"):
>>
>> "It must be noted that the incubator (just like the board) does not
>> perform filtering on the basis of technical issues. This is because
>> the foundation respects and suggests variety of technical
>> approaches. It doesn't fear innovation or even internal
>> confrontation between projects which overlap in functionality."
>>
>
> right and as long as OpenCMIS fulfills the requirements of the
> incubator I don't see any reason why there shouldn't be two projects
> of the same topic.
>
> I also do not see any reason why OpenCMIS should be a sub-project of
> Chemistry.
> Give it a chance of its own within the current rules of the
> incubator and it will either work or not.
> If it works, then graduate, if not, then remove it.
>
> Or am I missing something which violates any current rule of the
> incubator?
>
> Cheers
>
> Michael
>> Florian
>>
>> -----Original Message-----
>> From: Stefane Fermigier [mailto:sf@nuxeo.com] Sent: Friday,
>> December 11, 2009 7:46 PM
>> To: chemistry-dev@incubator.apache.org
>> Cc: Incubator-General
>> Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
>> Interoperability Services (CMIS)
>>
>>
>> On Dec 11, 2009, at 7:10 PM, Florian Müller wrote:
>>
>>> Chemistry uses Abdera to communicate with the server while
>>> OpenCMIS is based on JAX-B and some CMIS specific XML coding.
>>>
>>
>> I've been personally asking myself recently wether it would be
>> feasible to drop Abdera in favor of JAXB in Chemistry, so IMHO
>> it's something that should be discussed together and not a
>> division line for us.
>>
>>
>>> There is a lot of code sharing between the AtomPub and the Web
>>> Services binding. (I couldn't find a Web Services client in
>>> Chemistry.
>>>
>>
>> It would be great if you could contribute one.
>>
>>
>>> Here we are with a working code base that we cannot give up and
>>> that we will maintain in the future for obvious reasons. Our idea
>>> was to make it Open Source and let others benefit from our work.
>>> Apache seemed to be the right place - at least three days ago.
>>>
>>
>> OK, I'm new to this Apache thing, but I don't believe this is the
>> Apache Way. See: http://theapacheway.com/ or http://www.slideshare.net/jaaronfarr/the-apache-way-hk-sfd-2009
>>
>> S.
>>
>> --
>> Stefane Fermigier, Founder and Chairman, Nuxeo
>> Open Source, Java EE based, Enterprise Content Management (ECM)
>> Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
>> New: follow me on Twitter: http://twitter.com/sfermigier
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
New: follow me on Twitter: http://twitter.com/sfermigier
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Florent Guillaume <fg...@nuxeo.com>.
On Fri, Dec 11, 2009 at 11:18 PM, Michael Wechner
<mi...@wyona.com> wrote:
> Right and as long as OpenCMIS fulfills the requirements of the incubator I
> don't see any reason why there shouldn't be two projects of the same topic.
>
> I also do not see any reason why OpenCMIS should be a sub-project of
> Chemistry.
> Give it a chance of its own within the current rules of the incubator and it
> will either work or not.
> If it works, then graduate, if not, then remove it.
My concern is that if there are two separate svn trees then factoring
things between the two projects will be much harder. Let's not kid
ourselves, having two different maven release cycles, and having
dependencies to foreign SNAPSHOT projects, will not help. To me it's a
waste of time and effort.
Let me ask the question differently: what's lost by having the code in
the Chemistry svn tree?
Florent
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability
Services (CMIS)
Posted by Michael Wechner <mi...@wyona.com>.
Florian Müller wrote:
> Well, here is a citation from http://www.apache.org/foundation/how-it-works.html (section "The Foundation Incubator"):
>
> "It must be noted that the incubator (just like the board) does not perform filtering on the basis of technical issues. This is because the foundation respects and suggests variety of technical approaches. It doesn't fear innovation or even internal confrontation between projects which overlap in functionality."
>
right and as long as OpenCMIS fulfills the requirements of the incubator
I don't see any reason why there shouldn't be two projects of the same
topic.
I also do not see any reason why OpenCMIS should be a sub-project of
Chemistry.
Give it a chance of its own within the current rules of the incubator
and it will either work or not.
If it works, then graduate, if not, then remove it.
Or am I missing something which violates any current rule of the incubator?
Cheers
Michael
> Florian
>
> -----Original Message-----
> From: Stefane Fermigier [mailto:sf@nuxeo.com]
> Sent: Friday, December 11, 2009 7:46 PM
> To: chemistry-dev@incubator.apache.org
> Cc: Incubator-General
> Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
>
>
> On Dec 11, 2009, at 7:10 PM, Florian Müller wrote:
>
>> Chemistry uses Abdera to communicate with the server while OpenCMIS
>> is based on JAX-B and some CMIS specific XML coding.
>>
>
> I've been personally asking myself recently wether it would be
> feasible to drop Abdera in favor of JAXB in Chemistry, so IMHO it's
> something that should be discussed together and not a division line
> for us.
>
>
>> There is a lot of code sharing between the AtomPub and the Web
>> Services binding. (I couldn't find a Web Services client in Chemistry.
>>
>
> It would be great if you could contribute one.
>
>
>> Here we are with a working code base that we cannot give up and that
>> we will maintain in the future for obvious reasons. Our idea was to
>> make it Open Source and let others benefit from our work. Apache
>> seemed to be the right place - at least three days ago.
>>
>
> OK, I'm new to this Apache thing, but I don't believe this is the
> Apache Way. See: http://theapacheway.com/ or http://www.slideshare.net/jaaronfarr/the-apache-way-hk-sfd-2009
>
> S.
>
> --
> Stefane Fermigier, Founder and Chairman, Nuxeo
> Open Source, Java EE based, Enterprise Content Management (ECM)
> Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
> New: follow me on Twitter: http://twitter.com/sfermigier
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability
Services (CMIS)
Posted by Michael Wechner <mi...@wyona.com>.
Florian Müller wrote:
> Well, here is a citation from http://www.apache.org/foundation/how-it-works.html (section "The Foundation Incubator"):
>
> "It must be noted that the incubator (just like the board) does not perform filtering on the basis of technical issues. This is because the foundation respects and suggests variety of technical approaches. It doesn't fear innovation or even internal confrontation between projects which overlap in functionality."
>
right and as long as OpenCMIS fulfills the requirements of the incubator
I don't see any reason why there shouldn't be two projects of the same
topic.
I also do not see any reason why OpenCMIS should be a sub-project of
Chemistry.
Give it a chance of its own within the current rules of the incubator
and it will either work or not.
If it works, then graduate, if not, then remove it.
Or am I missing something which violates any current rule of the incubator?
Cheers
Michael
> Florian
>
> -----Original Message-----
> From: Stefane Fermigier [mailto:sf@nuxeo.com]
> Sent: Friday, December 11, 2009 7:46 PM
> To: chemistry-dev@incubator.apache.org
> Cc: Incubator-General
> Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
>
>
> On Dec 11, 2009, at 7:10 PM, Florian Müller wrote:
>
>> Chemistry uses Abdera to communicate with the server while OpenCMIS
>> is based on JAX-B and some CMIS specific XML coding.
>>
>
> I've been personally asking myself recently wether it would be
> feasible to drop Abdera in favor of JAXB in Chemistry, so IMHO it's
> something that should be discussed together and not a division line
> for us.
>
>
>> There is a lot of code sharing between the AtomPub and the Web
>> Services binding. (I couldn't find a Web Services client in Chemistry.
>>
>
> It would be great if you could contribute one.
>
>
>> Here we are with a working code base that we cannot give up and that
>> we will maintain in the future for obvious reasons. Our idea was to
>> make it Open Source and let others benefit from our work. Apache
>> seemed to be the right place - at least three days ago.
>>
>
> OK, I'm new to this Apache thing, but I don't believe this is the
> Apache Way. See: http://theapacheway.com/ or http://www.slideshare.net/jaaronfarr/the-apache-way-hk-sfd-2009
>
> S.
>
> --
> Stefane Fermigier, Founder and Chairman, Nuxeo
> Open Source, Java EE based, Enterprise Content Management (ECM)
> Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
> New: follow me on Twitter: http://twitter.com/sfermigier
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Florian Müller <fm...@opentext.com>.
Well, here is a citation from http://www.apache.org/foundation/how-it-works.html (section "The Foundation Incubator"):
"It must be noted that the incubator (just like the board) does not perform filtering on the basis of technical issues. This is because the foundation respects and suggests variety of technical approaches. It doesn't fear innovation or even internal confrontation between projects which overlap in functionality."
Florian
-----Original Message-----
From: Stefane Fermigier [mailto:sf@nuxeo.com]
Sent: Friday, December 11, 2009 7:46 PM
To: chemistry-dev@incubator.apache.org
Cc: Incubator-General
Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
On Dec 11, 2009, at 7:10 PM, Florian Müller wrote:
>
> Chemistry uses Abdera to communicate with the server while OpenCMIS
> is based on JAX-B and some CMIS specific XML coding.
I've been personally asking myself recently wether it would be
feasible to drop Abdera in favor of JAXB in Chemistry, so IMHO it's
something that should be discussed together and not a division line
for us.
> There is a lot of code sharing between the AtomPub and the Web
> Services binding. (I couldn't find a Web Services client in Chemistry.
It would be great if you could contribute one.
> Here we are with a working code base that we cannot give up and that
> we will maintain in the future for obvious reasons. Our idea was to
> make it Open Source and let others benefit from our work. Apache
> seemed to be the right place - at least three days ago.
OK, I'm new to this Apache thing, but I don't believe this is the
Apache Way. See: http://theapacheway.com/ or http://www.slideshare.net/jaaronfarr/the-apache-way-hk-sfd-2009
S.
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
New: follow me on Twitter: http://twitter.com/sfermigier
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Florian Müller <fm...@opentext.com>.
Well, here is a citation from http://www.apache.org/foundation/how-it-works.html (section "The Foundation Incubator"):
"It must be noted that the incubator (just like the board) does not perform filtering on the basis of technical issues. This is because the foundation respects and suggests variety of technical approaches. It doesn't fear innovation or even internal confrontation between projects which overlap in functionality."
Florian
-----Original Message-----
From: Stefane Fermigier [mailto:sf@nuxeo.com]
Sent: Friday, December 11, 2009 7:46 PM
To: chemistry-dev@incubator.apache.org
Cc: Incubator-General
Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
On Dec 11, 2009, at 7:10 PM, Florian Müller wrote:
>
> Chemistry uses Abdera to communicate with the server while OpenCMIS
> is based on JAX-B and some CMIS specific XML coding.
I've been personally asking myself recently wether it would be
feasible to drop Abdera in favor of JAXB in Chemistry, so IMHO it's
something that should be discussed together and not a division line
for us.
> There is a lot of code sharing between the AtomPub and the Web
> Services binding. (I couldn't find a Web Services client in Chemistry.
It would be great if you could contribute one.
> Here we are with a working code base that we cannot give up and that
> we will maintain in the future for obvious reasons. Our idea was to
> make it Open Source and let others benefit from our work. Apache
> seemed to be the right place - at least three days ago.
OK, I'm new to this Apache thing, but I don't believe this is the
Apache Way. See: http://theapacheway.com/ or http://www.slideshare.net/jaaronfarr/the-apache-way-hk-sfd-2009
S.
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
New: follow me on Twitter: http://twitter.com/sfermigier
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Stefane Fermigier <sf...@nuxeo.com>.
On Dec 11, 2009, at 7:10 PM, Florian Müller wrote:
>
> Chemistry uses Abdera to communicate with the server while OpenCMIS
> is based on JAX-B and some CMIS specific XML coding.
I've been personally asking myself recently wether it would be
feasible to drop Abdera in favor of JAXB in Chemistry, so IMHO it's
something that should be discussed together and not a division line
for us.
> There is a lot of code sharing between the AtomPub and the Web
> Services binding. (I couldn't find a Web Services client in Chemistry.
It would be great if you could contribute one.
> Here we are with a working code base that we cannot give up and that
> we will maintain in the future for obvious reasons. Our idea was to
> make it Open Source and let others benefit from our work. Apache
> seemed to be the right place - at least three days ago.
OK, I'm new to this Apache thing, but I don't believe this is the
Apache Way. See: http://theapacheway.com/ or http://www.slideshare.net/jaaronfarr/the-apache-way-hk-sfd-2009
S.
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
New: follow me on Twitter: http://twitter.com/sfermigier
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Stefane Fermigier <sf...@nuxeo.com>.
On Dec 11, 2009, at 7:10 PM, Florian Müller wrote:
>
> Chemistry uses Abdera to communicate with the server while OpenCMIS
> is based on JAX-B and some CMIS specific XML coding.
I've been personally asking myself recently wether it would be
feasible to drop Abdera in favor of JAXB in Chemistry, so IMHO it's
something that should be discussed together and not a division line
for us.
> There is a lot of code sharing between the AtomPub and the Web
> Services binding. (I couldn't find a Web Services client in Chemistry.
It would be great if you could contribute one.
> Here we are with a working code base that we cannot give up and that
> we will maintain in the future for obvious reasons. Our idea was to
> make it Open Source and let others benefit from our work. Apache
> seemed to be the right place - at least three days ago.
OK, I'm new to this Apache thing, but I don't believe this is the
Apache Way. See: http://theapacheway.com/ or http://www.slideshare.net/jaaronfarr/the-apache-way-hk-sfd-2009
S.
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
New: follow me on Twitter: http://twitter.com/sfermigier
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Florian Müller <fm...@opentext.com>.
Hi Jukka,
In the end the APIs should be somewhat similar since they are implementing the same spec.
But you are actually comparing two different levels of APIs. The opencmis-provider-api handles simple immutable data objects while chemistry-api follows an object-oriented approach. As far as I know Chemistry has nothing comparable to the opencmis-provider-api. The opencmis-client-api would be the right level to look at but the code of this API is not in SVN yet. We will make available on Monday.
The APIs are not the main reason why I think that Chemistry and OpenCMIS are different. (I would like to avoid the word "superior". I never used that in this context. Both projects came from a different background that's why they are different.)
Chemistry uses Abdera to communicate with the server while OpenCMIS is based on JAX-B and some CMIS specific XML coding. There is a lot of code sharing between the AtomPub and the Web Services binding. (I couldn't find a Web Services client in Chemistry. So I can't comment on that.) OpenCMIS has a caching infrastructure that is specific to CMIS and how OpenCMIS work. There is nothing like that in Chemistry. The overall architecture and principals below the API are very, very different. Bringing both together would require philosophy changes on both sides. I'm not saying that this isn't possible, but it's a lengthy process.
We derived our design from a lot of prototypes and applications that we have built over the past 20 months. Some code fragments and concepts are actually pretty old now. We had a lot of it in one shape or another when Chemistry started. That's why Chemistry was never an option for us. The code bases of Chemistry and OpenCMIS have been developed at the same time taking different routes. Chemistry did that in the public, most of OpenCMIS was created behind closed doors.
Here we are with a working code base that we cannot give up and that we will maintain in the future for obvious reasons. Our idea was to make it Open Source and let others benefit from our work. Apache seemed to be the right place - at least three days ago. It was never meant to be an attack against Chemistry.
Florian
-----Original Message-----
From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
Sent: Friday, December 11, 2009 5:24 PM
To: chemistry-dev@incubator.apache.org
Cc: Incubator-General
Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Hi,
On Fri, Dec 11, 2009 at 4:44 PM, Florian Müller <fm...@opentext.com> wrote:
> The only way to overcome this is to merge the OpenCMIS code into the
> Chemistry code base. But the technical approaches of the projects are so
> different that this might not work - at least not in the short term.
I compared opencmis-provider-api to chemistry-api. While there are
differences in design (granularity of interfaces, type safety, etc.),
the fundamental architecture is the same for both projects. This is as
expected as they both map the same standard to Java.
Are there some specific reasons why one design is superior to the
other? The only major difference I could quickly spot is the
ExtensionsData structure that OpenCMIS seems to include in almost all
method signatures. Other than that it looks like it would be fairly
straightforward to map from one API to another.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Florent Guillaume <fg...@nuxeo.com>.
On Fri, Dec 11, 2009 at 5:24 PM, Jukka Zitting <ju...@gmail.com> wrote:
> I compared opencmis-provider-api to chemistry-api. While there are
> differences in design (granularity of interfaces, type safety, etc.),
> the fundamental architecture is the same for both projects. This is as
> expected as they both map the same standard to Java.
>
> Are there some specific reasons why one design is superior to the
> other? The only major difference I could quickly spot is the
> ExtensionsData structure that OpenCMIS seems to include in almost all
> method signatures. Other than that it looks like it would be fairly
> straightforward to map from one API to another.
I haven't had time to look at the OpenCMIS code yet.
If there are useful use cases for adding ExtensionsData then there's
no question that this'll get added to Chemistry. Note that the SOAP
bindings have this anyway, since this is required by the XSDs.
Florent
--
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: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Florian Müller <fm...@opentext.com>.
Hi Jukka,
In the end the APIs should be somewhat similar since they are implementing the same spec.
But you are actually comparing two different levels of APIs. The opencmis-provider-api handles simple immutable data objects while chemistry-api follows an object-oriented approach. As far as I know Chemistry has nothing comparable to the opencmis-provider-api. The opencmis-client-api would be the right level to look at but the code of this API is not in SVN yet. We will make available on Monday.
The APIs are not the main reason why I think that Chemistry and OpenCMIS are different. (I would like to avoid the word "superior". I never used that in this context. Both projects came from a different background that's why they are different.)
Chemistry uses Abdera to communicate with the server while OpenCMIS is based on JAX-B and some CMIS specific XML coding. There is a lot of code sharing between the AtomPub and the Web Services binding. (I couldn't find a Web Services client in Chemistry. So I can't comment on that.) OpenCMIS has a caching infrastructure that is specific to CMIS and how OpenCMIS work. There is nothing like that in Chemistry. The overall architecture and principals below the API are very, very different. Bringing both together would require philosophy changes on both sides. I'm not saying that this isn't possible, but it's a lengthy process.
We derived our design from a lot of prototypes and applications that we have built over the past 20 months. Some code fragments and concepts are actually pretty old now. We had a lot of it in one shape or another when Chemistry started. That's why Chemistry was never an option for us. The code bases of Chemistry and OpenCMIS have been developed at the same time taking different routes. Chemistry did that in the public, most of OpenCMIS was created behind closed doors.
Here we are with a working code base that we cannot give up and that we will maintain in the future for obvious reasons. Our idea was to make it Open Source and let others benefit from our work. Apache seemed to be the right place - at least three days ago. It was never meant to be an attack against Chemistry.
Florian
-----Original Message-----
From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
Sent: Friday, December 11, 2009 5:24 PM
To: chemistry-dev@incubator.apache.org
Cc: Incubator-General
Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Hi,
On Fri, Dec 11, 2009 at 4:44 PM, Florian Müller <fm...@opentext.com> wrote:
> The only way to overcome this is to merge the OpenCMIS code into the
> Chemistry code base. But the technical approaches of the projects are so
> different that this might not work - at least not in the short term.
I compared opencmis-provider-api to chemistry-api. While there are
differences in design (granularity of interfaces, type safety, etc.),
the fundamental architecture is the same for both projects. This is as
expected as they both map the same standard to Java.
Are there some specific reasons why one design is superior to the
other? The only major difference I could quickly spot is the
ExtensionsData structure that OpenCMIS seems to include in almost all
method signatures. Other than that it looks like it would be fairly
straightforward to map from one API to another.
BR,
Jukka Zitting
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Florent Guillaume <fg...@nuxeo.com>.
On Fri, Dec 11, 2009 at 5:24 PM, Jukka Zitting <ju...@gmail.com> wrote:
> I compared opencmis-provider-api to chemistry-api. While there are
> differences in design (granularity of interfaces, type safety, etc.),
> the fundamental architecture is the same for both projects. This is as
> expected as they both map the same standard to Java.
>
> Are there some specific reasons why one design is superior to the
> other? The only major difference I could quickly spot is the
> ExtensionsData structure that OpenCMIS seems to include in almost all
> method signatures. Other than that it looks like it would be fairly
> straightforward to map from one API to another.
I haven't had time to look at the OpenCMIS code yet.
If there are useful use cases for adding ExtensionsData then there's
no question that this'll get added to Chemistry. Note that the SOAP
bindings have this anyway, since this is required by the XSDs.
Florent
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Dec 11, 2009 at 4:44 PM, Florian Müller <fm...@opentext.com> wrote:
> The only way to overcome this is to merge the OpenCMIS code into the
> Chemistry code base. But the technical approaches of the projects are so
> different that this might not work - at least not in the short term.
I compared opencmis-provider-api to chemistry-api. While there are
differences in design (granularity of interfaces, type safety, etc.),
the fundamental architecture is the same for both projects. This is as
expected as they both map the same standard to Java.
Are there some specific reasons why one design is superior to the
other? The only major difference I could quickly spot is the
ExtensionsData structure that OpenCMIS seems to include in almost all
method signatures. Other than that it looks like it would be fairly
straightforward to map from one API to another.
BR,
Jukka Zitting
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Dec 11, 2009 at 5:48 PM, Stefane Fermigier <sf...@nuxeo.com> wrote:
> ...More seriously, let's not attack each other's conception of open source, and
> focus on the question at hand....
+1
>
> ...Everyone, member of the open source community or not, is free to start a new
> implementation of an existing piece of software or library. This is a good
> thing when the existing software is in maintenance mode and not evolving
> anymore, or so crufty that a new design is needed, etc. But when we are
> speaking of two young projects, under the umbrella of the same organisation,
> I think this is very wrong....
I'm not involved in Chemistry so speaking from my overall Apache (and
incubator, as a serial mentor of sorts) point of view.
I wouldn't make that as strong ("very wrong") as Stéfane puts it -
having competing projects can be good, but in this case, with a young
technology like CMIS it's probably much better to join forces as
opposed to competing.
Apache is about building communities, and if a strong one can be built
as opposed to two weaker ones that's a big plus.
I like Florent's idea to bring the OpenCMIS code in Chemistry in a
separate tree at first, and factor out the common parts. Having two
parallel implementations in the same project is somewhat unusuall, but
not unheard of - and certainly not a problem for such bleeding edge
stuff, IMHO.
-Bertrand
(full disclosure: I work for Day Software and some of my colleagues
are involved in Chemistry)
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Dec 11, 2009 at 5:48 PM, Stefane Fermigier <sf...@nuxeo.com> wrote:
> ...More seriously, let's not attack each other's conception of open source, and
> focus on the question at hand....
+1
>
> ...Everyone, member of the open source community or not, is free to start a new
> implementation of an existing piece of software or library. This is a good
> thing when the existing software is in maintenance mode and not evolving
> anymore, or so crufty that a new design is needed, etc. But when we are
> speaking of two young projects, under the umbrella of the same organisation,
> I think this is very wrong....
I'm not involved in Chemistry so speaking from my overall Apache (and
incubator, as a serial mentor of sorts) point of view.
I wouldn't make that as strong ("very wrong") as Stéfane puts it -
having competing projects can be good, but in this case, with a young
technology like CMIS it's probably much better to join forces as
opposed to competing.
Apache is about building communities, and if a strong one can be built
as opposed to two weaker ones that's a big plus.
I like Florent's idea to bring the OpenCMIS code in Chemistry in a
separate tree at first, and factor out the common parts. Having two
parallel implementations in the same project is somewhat unusuall, but
not unheard of - and certainly not a problem for such bleeding edge
stuff, IMHO.
-Bertrand
(full disclosure: I work for Day Software and some of my colleagues
are involved in Chemistry)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Stefane Fermigier <sf...@nuxeo.com>.
On Dec 11, 2009, at 5:28 PM, Jens Hübel wrote:
> Hi Chemistry,
>
> I understand the concerns you might have and the confusion we have
> caused. But please do not forget that Open in Open Source has a
> meaning. So I am not sure that all the comments I read here are in
> accordance with the idea of it.
I don't know what's *your* idea of open source, but I stand by my
comments and I've been practicing and advocating open source since 1991.
More seriously, let's not attack each other's conception of open
source, and focus on the question at hand.
Everyone, member of the open source community or not, is free to start
a new implementation of an existing piece of software or library. This
is a good thing when the existing software is in maintenance mode and
not evolving anymore, or so crufty that a new design is needed, etc.
But when we are speaking of two young projects, under the umbrella of
the same organisation, I think this is very wrong.
S.
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
New: follow me on Twitter: http://twitter.com/sfermigier
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Ugo Cei <u....@sourcesense.com>.
On Dec 11, 2009, at 5:28 PM, Jens Hübel wrote:
> All I am saying is just be open....
Being open is OK, but having a separate project in incubator is just confusing.
I'm all for
1) accepting the code under the Chemistry tree as an alternative client implementation
2) trying to see if the two approaches can be merged or
2b) letting the developers choose the best implementation
Ugo
--
Ugo Cei
Sourcesense - making sense of Open Source: http://www.sourcesense.com
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Stefane Fermigier <sf...@nuxeo.com>.
On Dec 11, 2009, at 5:28 PM, Jens Hübel wrote:
> Hi Chemistry,
>
> I understand the concerns you might have and the confusion we have
> caused. But please do not forget that Open in Open Source has a
> meaning. So I am not sure that all the comments I read here are in
> accordance with the idea of it.
I don't know what's *your* idea of open source, but I stand by my
comments and I've been practicing and advocating open source since 1991.
More seriously, let's not attack each other's conception of open
source, and focus on the question at hand.
Everyone, member of the open source community or not, is free to start
a new implementation of an existing piece of software or library. This
is a good thing when the existing software is in maintenance mode and
not evolving anymore, or so crufty that a new design is needed, etc.
But when we are speaking of two young projects, under the umbrella of
the same organisation, I think this is very wrong.
S.
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
New: follow me on Twitter: http://twitter.com/sfermigier
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Jens Hübel <jh...@opentext.com>.
Hi Chemistry,
I understand the concerns you might have and the confusion we have caused. But please do not forget that Open in Open Source has a meaning. So I am not sure that all the comments I read here are in accordance with the idea of it. So before you just say "No" please think about
- If alternative solutions, competitive development is by itself a bad thing
- alternatives means that a customer can choose
- alternatives allow us in an open environment to pick the best from what you have and what we have
- implemented alternatives are the best way to judge what the best solution is (for a certain task)
All I am saying is just be open....
Jens
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Jens Hübel <jh...@opentext.com>.
Hi Chemistry,
I understand the concerns you might have and the confusion we have caused. But please do not forget that Open in Open Source has a meaning. So I am not sure that all the comments I read here are in accordance with the idea of it. So before you just say "No" please think about
- If alternative solutions, competitive development is by itself a bad thing
- alternatives means that a customer can choose
- alternatives allow us in an open environment to pick the best from what you have and what we have
- implemented alternatives are the best way to judge what the best solution is (for a certain task)
All I am saying is just be open....
Jens
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Stefane Fermigier <sf...@nuxeo.com>.
On Dec 11, 2009, at 4:44 PM, Florian Müller wrote:
> Hi Stefane,
>
> I'm not sure I get your point. If OpenCMIS would become a top level
> subproject within Chemistry (which is what Florent suggested) then
> those two topics would still remain. It would be even worse:
> Chemistry would then have two client APIs which would be really
> confusing.
>
> The only way to overcome this is to merge the OpenCMIS code into the
> Chemistry code base. But the technical approaches of the projects
> are so different that this might not work - at least not in the
> short term.
>
> Or is your message that you don't want OpenCMIS code at all on Apache?
My message is that I don't think we should have two different,
competing CMIS client APIs in Apache, specially if they start being
developed at the roughly the same time.
S.
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
New: follow me on Twitter: http://twitter.com/sfermigier
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement
Interoperability Services (CMIS)
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Dec 11, 2009 at 4:44 PM, Florian Müller <fm...@opentext.com> wrote:
> The only way to overcome this is to merge the OpenCMIS code into the
> Chemistry code base. But the technical approaches of the projects are so
> different that this might not work - at least not in the short term.
I compared opencmis-provider-api to chemistry-api. While there are
differences in design (granularity of interfaces, type safety, etc.),
the fundamental architecture is the same for both projects. This is as
expected as they both map the same standard to Java.
Are there some specific reasons why one design is superior to the
other? The only major difference I could quickly spot is the
ExtensionsData structure that OpenCMIS seems to include in almost all
method signatures. Other than that it looks like it would be fairly
straightforward to map from one API to another.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Stefane Fermigier <sf...@nuxeo.com>.
On Dec 11, 2009, at 4:44 PM, Florian Müller wrote:
> Hi Stefane,
>
> I'm not sure I get your point. If OpenCMIS would become a top level
> subproject within Chemistry (which is what Florent suggested) then
> those two topics would still remain. It would be even worse:
> Chemistry would then have two client APIs which would be really
> confusing.
>
> The only way to overcome this is to merge the OpenCMIS code into the
> Chemistry code base. But the technical approaches of the projects
> are so different that this might not work - at least not in the
> short term.
>
> Or is your message that you don't want OpenCMIS code at all on Apache?
My message is that I don't think we should have two different,
competing CMIS client APIs in Apache, specially if they start being
developed at the roughly the same time.
S.
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
New: follow me on Twitter: http://twitter.com/sfermigier
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Florian Müller <fm...@opentext.com>.
Hi Stefane,
I'm not sure I get your point. If OpenCMIS would become a top level subproject within Chemistry (which is what Florent suggested) then those two topics would still remain. It would be even worse: Chemistry would then have two client APIs which would be really confusing.
The only way to overcome this is to merge the OpenCMIS code into the Chemistry code base. But the technical approaches of the projects are so different that this might not work - at least not in the short term.
Or is your message that you don't want OpenCMIS code at all on Apache?
Florian
-----Original Message-----
From: Stefane Fermigier [mailto:sf@nuxeo.com]
Sent: Friday, December 11, 2009 3:52 PM
To: chemistry-dev@incubator.apache.org
Cc: Incubator-General
Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Same for me (if I understand your opinion correctly): we shouldn't
have OpenCMIS competing with a subproject of Chemistry, because it
will have a negative impact both internally (on project developers)
and externally (on project customers):
1. Internally: duplication of effort, instead of focussing on
providing the best possible API.
2. Externally: blurred message, two different API / models to learn.
S.
On Dec 11, 2009, at 2:35 PM, Ugo Cei wrote:
>
> On Dec 10, 2009, at 4:00 PM, Florent Guillaume wrote:
>
>> My earlier recommendation to Paul and Florian, and my recommendation
>> today, is that, if incubating is deemed the better choice, OpenCMIS
>> become a top level directory under the Chemistry codebase. The
>> earlier
>> the two codebases are brought together, the earlier we can start
>> factoring things (and there are quite a few boilerplates in the CMIS
>> spec). IMHO it would also be nice if the high-level APIs could
>> converge, as they are what the Java programmer will see and, when it
>> makes sense, we should reduce confusion.
>
>
> Here's my +1 from the peanut gallery. I personally don't find the
> idea of incubating OpenCMIS appealing at all.
>
> Ugo
>
> --
> Ugo Cei
> Sourcesense - making sense of Open Source: http://www.sourcesense.com
>
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
New: follow me on Twitter: http://twitter.com/sfermigier
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Florian Müller <fm...@opentext.com>.
Hi Stefane,
I'm not sure I get your point. If OpenCMIS would become a top level subproject within Chemistry (which is what Florent suggested) then those two topics would still remain. It would be even worse: Chemistry would then have two client APIs which would be really confusing.
The only way to overcome this is to merge the OpenCMIS code into the Chemistry code base. But the technical approaches of the projects are so different that this might not work - at least not in the short term.
Or is your message that you don't want OpenCMIS code at all on Apache?
Florian
-----Original Message-----
From: Stefane Fermigier [mailto:sf@nuxeo.com]
Sent: Friday, December 11, 2009 3:52 PM
To: chemistry-dev@incubator.apache.org
Cc: Incubator-General
Subject: Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Same for me (if I understand your opinion correctly): we shouldn't
have OpenCMIS competing with a subproject of Chemistry, because it
will have a negative impact both internally (on project developers)
and externally (on project customers):
1. Internally: duplication of effort, instead of focussing on
providing the best possible API.
2. Externally: blurred message, two different API / models to learn.
S.
On Dec 11, 2009, at 2:35 PM, Ugo Cei wrote:
>
> On Dec 10, 2009, at 4:00 PM, Florent Guillaume wrote:
>
>> My earlier recommendation to Paul and Florian, and my recommendation
>> today, is that, if incubating is deemed the better choice, OpenCMIS
>> become a top level directory under the Chemistry codebase. The
>> earlier
>> the two codebases are brought together, the earlier we can start
>> factoring things (and there are quite a few boilerplates in the CMIS
>> spec). IMHO it would also be nice if the high-level APIs could
>> converge, as they are what the Java programmer will see and, when it
>> makes sense, we should reduce confusion.
>
>
> Here's my +1 from the peanut gallery. I personally don't find the
> idea of incubating OpenCMIS appealing at all.
>
> Ugo
>
> --
> Ugo Cei
> Sourcesense - making sense of Open Source: http://www.sourcesense.com
>
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
New: follow me on Twitter: http://twitter.com/sfermigier
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Stefane Fermigier <sf...@nuxeo.com>.
Same for me (if I understand your opinion correctly): we shouldn't
have OpenCMIS competing with a subproject of Chemistry, because it
will have a negative impact both internally (on project developers)
and externally (on project customers):
1. Internally: duplication of effort, instead of focussing on
providing the best possible API.
2. Externally: blurred message, two different API / models to learn.
S.
On Dec 11, 2009, at 2:35 PM, Ugo Cei wrote:
>
> On Dec 10, 2009, at 4:00 PM, Florent Guillaume wrote:
>
>> My earlier recommendation to Paul and Florian, and my recommendation
>> today, is that, if incubating is deemed the better choice, OpenCMIS
>> become a top level directory under the Chemistry codebase. The
>> earlier
>> the two codebases are brought together, the earlier we can start
>> factoring things (and there are quite a few boilerplates in the CMIS
>> spec). IMHO it would also be nice if the high-level APIs could
>> converge, as they are what the Java programmer will see and, when it
>> makes sense, we should reduce confusion.
>
>
> Here's my +1 from the peanut gallery. I personally don't find the
> idea of incubating OpenCMIS appealing at all.
>
> Ugo
>
> --
> Ugo Cei
> Sourcesense - making sense of Open Source: http://www.sourcesense.com
>
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
New: follow me on Twitter: http://twitter.com/sfermigier
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Posted by Stefane Fermigier <sf...@nuxeo.com>.
Same for me (if I understand your opinion correctly): we shouldn't
have OpenCMIS competing with a subproject of Chemistry, because it
will have a negative impact both internally (on project developers)
and externally (on project customers):
1. Internally: duplication of effort, instead of focussing on
providing the best possible API.
2. Externally: blurred message, two different API / models to learn.
S.
On Dec 11, 2009, at 2:35 PM, Ugo Cei wrote:
>
> On Dec 10, 2009, at 4:00 PM, Florent Guillaume wrote:
>
>> My earlier recommendation to Paul and Florian, and my recommendation
>> today, is that, if incubating is deemed the better choice, OpenCMIS
>> become a top level directory under the Chemistry codebase. The
>> earlier
>> the two codebases are brought together, the earlier we can start
>> factoring things (and there are quite a few boilerplates in the CMIS
>> spec). IMHO it would also be nice if the high-level APIs could
>> converge, as they are what the Java programmer will see and, when it
>> makes sense, we should reduce confusion.
>
>
> Here's my +1 from the peanut gallery. I personally don't find the
> idea of incubating OpenCMIS appealing at all.
>
> Ugo
>
> --
> Ugo Cei
> Sourcesense - making sense of Open Source: http://www.sourcesense.com
>
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
Web: http://www.nuxeo.com/ - Tel: +33 1 40 33 79 87
New: follow me on Twitter: http://twitter.com/sfermigier