incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert burrell donkin" <>
Subject Re: Re: [VOTE] publish openjpa 0.9.6-incubating release
Date Sat, 18 Nov 2006 14:49:06 GMT
On 11/17/06, Marc Prud'hommeaux <> wrote:
> On Nov 16, 2006, at 12:57 PM, robert burrell donkin wrote:
> > On 11/16/06, Marc Prud'hommeaux <> wrote:


> > i have some issues i'd like to see fixed plus less important issues,
> > some questions i'd like answered and some comments just FYI
> >
> > -- issues (i would like to see fixed) --


> > openjpa distributes some jars in the binary. NOTICE.txt is ok (but
> > note now asks that apache
> > collective copyright is included) but their licenses are not included
> > in LICENSE.txt. see
> > for example.
> The only two non-ASF jars in the distribution are serp-1.11.0.jar
> (BSD license) and persistence-api-1.0.jar (Sun CDDL). I've added
> their licenses into our LICENSE.txt. I'd appreciate if you could take
> a glance at the text (at
> openjpa/trunk/openjpa-project/LICENSE.txt ) and let me know if that
> looks sufficient.

looks good :-)

> Also, I don't think I need to add the licenses for the ASF jars that
> are included with the binaries. If I'm incorrect about that, please
> let me know, and I'll paste in the text of their identical licenses
> to our LICENSE.txt file.

no need to add duplicate copies of each particular LICENSE

the aim is to inform downstream users in particular packages about the
LICENSE for each artifact distributed. this is good for both legal and
social reasons. it's up to the project how they achieve this goal.
there are other acceptable ways used but the example is a commonly
used approach.

> > source distribution is missing LICENSE, NOTICE and DISCLAIMER at the
> > top level. (these probably need to be commit into svn.)
> As an exact snapshot of the buildable sources, these files were
> included in the "openjpa-project" sub-directory of the sources
> package. Reviewing
> headers.html#notice , I see that they need to be included in the top
> directory of any artifact, so I've added a directive to the source
> distribution build to add them there.

(i personally distrust source distribution processing of any kind. i
worry about reproducability. but this is a matter for the project so)
that should be ok

> > -- minor issues --
> >
> >
> > incubating/src/site/apt/*.apt
> > lack license headers. apt supports comments so these should probably
> > have headers.
> I've added license headers to these files. I hadn't realized that apt
> supported comments.

seems to be an under-advertised feature :-)

> > -- questions --
> >
> > i can't find LICENSE, NOTICE or DISCLAIMER in
> > openjpa-all-0.9.6-incubating.jar. did you intend to prevent official
> > distribution through maven repositories?
> Oops ... we missed putting these in. I've corrected this for the
> LICENSE.txt and NOTICE.txt files. However, looking at http://
> , I don't see any
> mention of including the DISCLAIMER file ... is there somewhere else
> that mentions that that file should be included in jars (or other
> binary artifacts)?

you won't find it since this is not a general requirement for apache
releases :-)

the IPMC requires a disclaimer text is distributed with each artifact.
i guessed that since openjpa uses a DISCLAIMER.txt that it would make
sense to include this. feel free to shoot me down if you already
include the disclaimer in some other form.

> > (RAT)
> >
> >
> > incubating/openjpa-jdbc/src/main/resources/org/apache/openjpa/jdbc/
> > schema/schemas-doctype.rsrc
> > has no license header. is this a generated file?
> No, but I don't think the format supports comments.

i'm going to assume that it's a DTD

AIUI it's possible to include xml style comments (<!-- -->) in all
parsed entities (those that start with a prolog for example <?xml
version='1.0'?>) but i'm willing to stand corrected...

this isn't a release stopper for me

> >
> > incubating/openjpa-persistence/src/main/resources/org/apache/
> > openjpa/persistence/orm-xsd.rsrc
> > has no license header. is this a generated file?
> I'm not sure what to do about that one ... it is a cached copy of
> which we use for
> XML schema validation without having to go to the web (which would be
> prohibitive). The original schema doesn't specify any license, and
> I'm not sure what the implicit license would be, but I also wouldn't
> feel right about sticking in an Apache license header for a file that
> we obviously didn't create.

exactly right: never just stick headers in anything without clear provinence

> Any thoughts?

in the absence of any clear license, there is a link at the bottom of which says arguable,
though, it's part of the RI which is probably LGPL'd.

but all this seems far too flimsy for comfort

i recommend taking this up on legal-discuss and (if possible)
contacting sun directly for clear guidance about their intended
license. it would be cleaner and clearer if they embedded the license
in the document or (at least) included the information in

unfortunately, this sounds like it might take a while to sort out :-/

might be quicker just to create a clean room implementation direct
from the specification

> > -- comments --
> >
> > --- notes and suggestions (for future reference) ---
> >
> > there is no need to create sums for detached signatures.
> Maven seems to automatically attach .md5 and .sha1 checksums to all
> uploaded artifacts. Since we are generating the .asc signatures in
> the Maven process, it seems to include these in the list of artifacts
> to sign. There doesn't seem to be any way to disable this, and the
> convenience gained by having these files generated and uploaded as
> part of the Maven build process outweighed the annoyance of having
> these vestigial checksums lying around (IMO).


> > some users (typically on *nix) prefer either bz2'd or tar.gz's
> > distributions. creating additional artifacts is quick and easy so this
> > is an easy way to make life just a little easier for some users.
> We briefly discussed this on the open-jpa-list. While it is certainly
> de-facto convention to release under both .zip and .tar.gz packaging
> types, the only compelling reason to do so appears to be that UNIX
> executable permissions are lost in the zip format. Since we don't
> have any executables in the openjpa distribution, there doesn't seem
> to be much reason to have additional packaging formats.
> We'd be interested in knowing if there are other advantages to having
> multiple packaging mechanisms, though.

releases are important guerrilla advertising for a project :-)

user expectation and convenience. users expect projects that produce
just zip'd distributions to be windows centric. distributions with
alternative compression are easy and quick to produce. so IMHO it
makes sense to distribute .tar.gz'd as well as zip'd just to make
*nix'ers feel at home. good for linux-centric grassroots news channels
(such as freshmeat) as well.

but it's for the community to decide so it's the debate that's important


> > there is no RELEASE_NOTES in the base directory. for open source
> > projects, these serve as an important communication to users. the
> > content will often serve for reuse in announcements and other
> > grassroots publicity. consider creating them for the next release.
> We don't have one since this is our initial release, so the whole
> package is effectively one big release note :)

RELEASE_NOTES are important guerrilla advertising for a project :-)

the content is often reused for announcements and for grassroots news
channels such as freshmeat. release notes should describe a project's
purpose and aims, how people can get involved, list sources of
information and give some general information about the project's

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message