chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Huebel, Jens" <j.hue...@sap.com>
Subject Re: [DISCUSSION] OpenCMIS 0.10.0
Date Tue, 13 Aug 2013 10:39:04 GMT
Sounds good to me Gab.

Florian and I will go through the remaining topics and come up with a
suggestion how to proceed with the 1.0 release.

Jens


On 13.08.13 11:00, "Gabriele Columbro" <columbro@gmail.com> wrote:

>On Tue, Aug 13, 2013 at 10:36 AM, Florian Müller <fmui@apache.org> wrote:
>
>> How about this:
>> We release 0.10.0 now, compile a road map, publish it and work on v1.0.
>>
>
>That seems a valid approach to me, as allow us to move on and because
>tasks
>can be easily parallelized.
>
>I will work and push out 0.10.0 as is for vote anyway and potentially
>complete the release this week. For the record, also because I feel a bit
>guilty for not having found time to push out 0.9.1 (and the WSDL major
>fixes coming with it) in due time...
>
>Still, I think Peter points are very spot on, and I this we should release
>1.0 very soon.
>
>So, in parallel, Florian can take the lead on discussing the roadmap in
>Jira / email / website. I have a couple of things myself I want to do from
>a release cleanup / handover standpoint for 1.0 so would be good to
>timebox
>1.0 and see what is possible.
>
>Deal? :)
>
>Thanks,
>
>Gab
>
>
>> Florian
>>
>>
>>
>>  G'day Florian,
>>>
>>> Yeah *I* understand that OpenCMIS is production grade - I've
>>> explicitly chosen to use it in several Alfresco products that I
>>> manage.  The problem is when I deliver that message to other
>>> prospective implementers it sometimes falls on deaf ears.
>>>
>>> Having the explanation below, or Dieter's quote, or similar may help
>>> such implementers to decide in favour of OpenCMIS.  Having a v1.0
>>> would be more effective.
>>>
>>> Cheers,
>>> Peter
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Aug 12, 2013, at 4:57 AM, Florian Müller <fmui@apache.org> wrote:
>>>
>>>  Hi Peter,
>>>>
>>>> OpenCMIS consists of multiple more or less independent parts. The
>>>> "serious flaw" was that the client library couldn't connect to a Web
>>>> Service endpoint anymore. That doesn't touch the server framework or
>>>>the
>>>> InMemory repository or the common parser classes or anything else.
>>>> Unfortunately, releasing OpenCMIS 0.9.1 as a bug fix release didn't
>>>>work
>>>> out. But that shouldn't stop us from improving other areas.
>>>>
>>>> OpenCMIS is used in many open source and commercial products and
>>>> productive scenarios today. But the JavaDoc could be improved and
>>>>some code
>>>> areas could need some more comments and clean up to make it better
>>>> maintainable. I think 'high quality' is also defined by these things.
>>>>Till
>>>> now we have focused on making it feature complete (-> CMIS 1.1) and
>>>>correct.
>>>> Personally, I would like to address the documentation and
>>>> maintainability areas before we release v1.0, even if it doesn't
>>>>change any
>>>> APIs and we could theoretically do this after v1.0 is released. But
>>>>that's
>>>> only my opinion. It should be a community decision.
>>>>
>>>> Apart from that, I guess OpenCMIS development will not stop for a long
>>>> time. At least the TCK will grow. But I can also envision support for
>>>>more
>>>> authentication methods (for example OAuth) and specific adaptations
>>>>for
>>>> certain environments (application servers, enterprise service buses,
>>>>JAX-WS
>>>> implementations, etc.).
>>>>
>>>>
>>>> - Florian
>>>>
>>>>
>>>>  If v0.9 had "serious flaws", I might ask why 0.10.0 adds "a new
>>>>> TypeFactory class and a couple of utility classes" and makes "changes
>>>>> for cleanup spread over hundreds of classes"?  Wouldn't a more
>>>>> conservative, fix-centric approach be more advisable?
>>>>>
>>>>> Regardless, I think the comment that "I do not see any reason to
>>>>> rush." concerns me the most.  CMIS v1.0 was released more than 3
>>>>>years
>>>>> ago and the argument has been made that there still isn't a stable,
>>>>> reliable client library available.  Clearly Apache Chemistry is not
>>>>>an
>>>>> official CMIS client library, but the goals of CMIS are hindered by
>>>>> this lack.
>>>>>
>>>>> Perhaps I'm misunderstanding the primary goal of the OpenCMIS
>>>>> sub-project though - is it to provide high quality Java CMIS client
>>>>> libraries, or is it more around client library experimentation?
>>>>>
>>>>> Cheers,
>>>>> Peter
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Aug 9, 2013, at 8:45 AM, Jay Brown <jay.brown@us.ibm.com> wrote:
>>>>>
>>>>>  I agree with Jens.  Make it 0.10.0.  Getting really close though.
>>>>>>
>>>>>> I will be doing a fair share of testing (server side OpenCMIS)
>>>>>>between
>>>>>> now and November that once completed will give me more confidence
>>>>>>as well.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Jay Brown
>>>>>> Senior Engineer, ECM Development
>>>>>> IBM Software Group
>>>>>> jay.brown@us.ibm.com
>>>>>>
>>>>>> "Huebel, Jens" ---08/08/2013 11:37:55 PM---Personally I feel that
>>>>>>this
>>>>>> is 0.10 and not a 1.0 release. It appeared that the previous one
>>>>>>0.9 had
>>>>>>
>>>>>>
>>>>>> From:
>>>>>>
>>>>>> "Huebel, Jens" <j.huebel@sap.com>
>>>>>>
>>>>>> To:
>>>>>>
>>>>>> "dev@chemistry.apache.org" <dev@chemistry.apache.org>,
>>>>>>
>>>>>> Date:
>>>>>>
>>>>>> 08/08/2013 11:37 PM
>>>>>>
>>>>>> Subject:
>>>>>>
>>>>>> Re: [DISCUSSION] OpenCMIS 0.10.0
>>>>>>
>>>>>>
>>>>>>
>>>>>> Personally I feel that this is 0.10 and not a 1.0 release.
>>>>>>
>>>>>> It appeared that the previous one 0.9 had some serious flaws which
>>>>>> made us
>>>>>> releasing another version pretty soon.
>>>>>>
>>>>>> With the current release we introduced a new TypeFactory class and
a
>>>>>> couple of utility classes being essential for the core functionality
>>>>>> of a
>>>>>> server if they are in use. This code saw the daylight only a couple
>>>>>>of
>>>>>> days ago and definitely needs a proof that it is reliable and
>>>>>>stable.
>>>>>> There also have been changes for cleanup spread over hundreds of
>>>>>> classes.
>>>>>> The InMemory server is not for production use and therefore is of
>>>>>>minor
>>>>>> importance but needs cleanup in some areas. I also feel that the
>>>>>> documentation is not in a 1.0 state yet.
>>>>>>
>>>>>> Nothing would be worse for our project than releasing a crippled
1.0
>>>>>> release after years of effort. And Peter I fear your users will
>>>>>> hesitate
>>>>>> to use this stuff forever if we run 1.0 into the weeds ;)
>>>>>>
>>>>>> I do not see any reason to rush. I agree to target a 1.0 release
for
>>>>>> the
>>>>>> fall, end-of-year time frame if we do not introduce new
>>>>>>functionality
>>>>>> since our last 0.x version. Isn't this good style for any project?
>>>>>>
>>>>>> Just my 2 cents
>>>>>>
>>>>>> Jens
>>>>>>
>>>>>>
>>>>>> On 08.08.13 20:23, "Florian Müller" <fmui@apache.org> wrote:
>>>>>>
>>>>>> >We can actually do both in parallel. Our release manager can
cut a
>>>>>> >0.10.0 release. Once we have a release candidate we can work
full
>>>>>> steam
>>>>>> >on 1.0. We don't have to wait for the release process to finish.
>>>>>> >
>>>>>> >Btw. Any help with the JavaDoc is very welcome. It would be great
>>>>>>if
>>>>>> >some native speakers could support us here.
>>>>>> >
>>>>>> >
>>>>>> >- Florian
>>>>>> >
>>>>>> >
>>>>>> >> Thanks Florian.  If a v1.0 is that close, I'd vote for doing
>>>>>> whatever's
>>>>>> >>necessary to get it to that point, even if it delays the
bug fixes
>>>>>> etc.
>>>>>> >>a bit.  I've had a little pushback (not much, but not zero
either)
>>>>>> from
>>>>>> >>potential users of the library because of a perception that
it's
>>>>>> >>"pre-release" (based solely on the version number, as best
I can
>>>>>> tell).
>>>>>> >>
>>>>>> >> Cheers,
>>>>>> >> Peter
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> On Aug 8, 2013, at 8:32 AM, Florian Müller <fmui@apache.org>
>>>>>>wrote:
>>>>>> >>
>>>>>> >>> We have full CMIS 1.1 support now.
>>>>>> >>> If the community feels comfortable calling it 1.0 we
can do
>>>>>>that.
>>>>>> Any
>>>>>> >>>opinions?
>>>>>> >>>
>>>>>> >>> I think we should improve the JavaDoc to a point that
it
>>>>>> sufficiently
>>>>>> >>>covers all public APIs and then call it 1.0. There are
also some
>>>>>> places
>>>>>> >>>that need cleaning. But I don't expect that we add any
major
>>>>>> >>>functionality in the near future.
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> - Florian
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>> On Thu, 8 Aug 2013, Peter Monks wrote:
>>>>>> >>>>> +1, but as a side note, what's the gating factor
on a v1.0?
>>>>>> >>>> Full CMIS v1.1 support might seem a good reason
for the version
>>>>>> bump?
>>>>>> >>>>
>>>>>> >>>> Nick
>>>>>> >>
>>>>>> >>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>
>
>-- 
>Gabriele Columbro
>Principal Architect, Consulting Services
>Alfresco Software <http://www.alfresco.com>
>twitter: @mindthegabz <http://twitter.com/#%21/mindthegabz>
>blog: http://mindthegab.com
>mobile: +31627565013


Mime
View raw message