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
<[email protected]> 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<[email protected]> 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<[email protected]>
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
