chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Müller <florian.muel...@alfresco.com>
Subject Re: Validation of release packages
Date Fri, 10 Sep 2010 13:54:56 GMT
You are right, we could (and probably should) be more intelligent in the 
high level client even though the binding doesn't support it.

If the user has fetched the object and didn't exclude the 
cmis:contentStreamFileName property we already have the filename in 
memory. If the user filtered that property out, I think the filename 
should remain null. Another getObject() call just for the filename is 
too expensive.


- Florian



On 10/09/2010 14:43, Florent Guillaume wrote:
> Yes I meant that.
> Ok so don't hold the release then.
>
> But this model mismatch makes some of my high-level unit tests fail
> when run on the atompub bindings, whereas they pass with webservices
> and local bindings.
> I think PersistentDocumentImpl.getContentStream should probably return
> an intelligent content stream object that knows to fetch the stream
> filename if requested.
>
> Florent
>
> On Fri, Sep 10, 2010 at 3:39 PM, Florian Müller
> <florian.mueller@alfresco.com>  wrote:
>> Hi Florent,
>>
>> You mean that the OpenCMIS client doesn't return a filename in the
>> ContentStream object when using AtomPub?
>>
>> That is correct. There is no filename in that case.
>>
>>
>> - Florian
>>
>>
>> On 10/09/2010 14:34, Florent Guillaume wrote:
>>>
>>> Can you hold the code freeze until 4PM ? There's I think a bug in the
>>> AtomPub bindings that I'd like to fix or make sure it's not a bug
>>> (getting the filename of a returned content stream).
>>>
>>> Florent
>>>
>>> On Fri, Sep 10, 2010 at 2:26 PM, Florent Guillaume<fg@nuxeo.com>    wrote:
>>>>
>>>> I really hate depending on anything SNAPSHOT during a release.
>>>> Although of course you could give it a date-based version, just
>>>> creating a new maven plugin for that for the first OpenCMIS release
>>>> seems overkill. Can't we do things partially by hand for now?
>>>>
>>>> Anyway, ok for the code freeze at 3PM CET.
>>>>
>>>> Florent
>>>>
>>>> On Fri, Sep 10, 2010 at 1:15 PM, Gabriele Columbro<gabriele@apache.org>
>>>>   wrote:
>>>>>
>>>>> Hey guys,
>>>>> quick update on this one: as Florian mentioned, working on the
>>>>> assumption
>>>>> the Category B licenses require a pointer to source code in NOTICE
>>>>> (apart
>>>>> from the mention in DEPENDENCIES), I have a working solution which
>>>>> allows
>>>>> maven to produce the notice file in the proper way.
>>>>> Basically I'm using a custom version of the apache-jar-resource-bundle,
>>>>> which lists in NOTICE all the CDDL licensed packages (CDDL is the only
>>>>> Category B dependency we have).
>>>>>
>>>>> Provided that I will pick this us on the Maven Dev list for a possible
>>>>> contribution, a quick solution for now is to:
>>>>>
>>>>> - create a top level project (out of the release, at the same level of
>>>>> the
>>>>> tck [1]), called chemistry-jar-resource-bundle
>>>>> - add the custom NOTICE.vm file there and deploy a SNAPSHOT to
>>>>> repository.apache.org
>>>>> - depend on it by our build and use it in the
>>>>> maven-remote-resource-plugin
>>>>> config
>>>>>
>>>>> I'll perform this right away, unless you guys have some concern.  I can
>>>>> later then proceed with the release (ideally I could call a code freeze,
>>>>> let's say, by 3PM CET ? )
>>>>>
>>>>> Let me know your thoughts,
>>>>> Gab
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> [1] http://svn.apache.org/repos/asf/incubator/chemistry/
>>>>>
>>>>>
>>>>>
>>>>> On Sep 9, 2010, at 3:17 PM, Florian Müller wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Gab and my interpretation of the Apache third-party rules [1] is
that
>>>>>> all
>>>>>> dependencies with Category B licences have to be mentioned in the
>>>>>> NOTICE
>>>>>> files with a link to the source code.
>>>>>>
>>>>>> We have a bunch of CDDL dependencies. The names and links are already
>>>>>> in
>>>>>> the DEPENDENCIES files. We think copying the CDDL entries to NOTICE
>>>>>> files
>>>>>> should sufficient.
>>>>>>
>>>>>>
>>>>>> Any comments? Experts?
>>>>>>
>>>>>>
>>>>>> - Florian
>>>>>>
>>>>>> [1] http://www.apache.org/legal/3party.html
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 08/09/2010 14:59, Nick Burch wrote:
>>>>>>>
>>>>>>> On Wed, 1 Sep 2010, Gabriele Columbro wrote:
>>>>>>>>
>>>>>>>> One question to conclude: referring to Nick's comments at
[4], do you
>>>>>>>> think we should have anything else in NOTICE for all packages?
In
>>>>>>>> other words, which of the licenses mentioned in the various
>>>>>>>> DEPENDENCIES files actually require a NOTICE?
>>>>>>>
>>>>>>> The NOTICE file should contain as little as possible. Everything
else
>>>>>>> should go in DEPENDENCIES, a readme, the website etc
>>>>>>>
>>>>>>> The reason for this is that every downstream user has to include
>>>>>>> everything in our NOTICE file in their own notices. So, we want
it to
>>>>>>> include all the required notices of our upstream dependencies,
along
>>>>>>> with our own notice. However, we don't want to full the NOTICE
file up
>>>>>>> with things that aren't required, as we don't want to burden
our
>>>>>>> users!
>>>>>>>
>>>>>>> To review the NOTICE files, take a look at what's in there, and
>>>>>>> compare
>>>>>>> that to the dependencies list (which is hopefully correct, since
maven
>>>>>>> generated it!). The notice file should have our notice in it,
and
>>>>>>> after
>>>>>>> that any dependency ones. If a dependency is under a license
that
>>>>>>> requires a notice, it should be there. (If not, it shouldn't.
The main
>>>>>>> apache 3rd party licenses page may give some help on this)
>>>>>>>
>>>>>>> Does this make sense to everyone?
>>>>>>>
>>>>>>> Nick
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Gabriele Columbro
>>>>> Alfresco Software, Ltd.
>>>>>
>>>>> http://www.mindthegab.com
>>>>> http://twitter.com/mindthegabz
>>>>>
>>>>> " Keyboard not found. Press F1 to continue."
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>>
>>>
>>
>>
>
>
>


Mime
View raw message