incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <>
Subject Re: [VOTE] publish openjpa 0.9.6-incubating release
Date Fri, 17 Nov 2006 00:30:20 GMT

We'll correct these issues asap. Once corrected artifacts are  
uploaded, I assume it will necessary to re-start the vote on the open- 
jpa-dev list before re-starting the vote here. Please correct me if I  
am wrong.

Responses to specific points are inline below...

On Nov 16, 2006, at 12:57 PM, robert burrell donkin wrote:

> On 11/16/06, Marc Prud'hommeaux <> wrote:
>> The OpenJPA incubator community voted on and has approved a proposal
>> to release OpenJPA 0.9.6-incubating. Pursuant to the Releases section
>> of the Incubation Policy (
>> Incubation_Policy.html#Releases ) we would now like to request the
>> permission of the Incubator PMC to publish the release zip file on
>> the openjpa download page (
>> downloads.html).
> 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) --
> has some unresolved
> copyright issues. i trust that this just means that the status page
> hasn't been updated.

I believe that the page just needs to be updated. I'll follow-up on  
the open-jpa-dev list to find out how to go about doing this.

> 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.

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.

> 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.

> -- 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.

> -- 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)?

> (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.

> 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.

Any thoughts?

> -- 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.

> i personally prefer the source and binary distributions to unpack to
> different directories but the overlay style (both unpack to the same
> directory forming a combined product) is also good if a little effort
> is invested into it.

This request was also made on the open-jpa-dev list. I've gone ahead  
and made the source assembly unpack to a different parent directory.

> 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 :)

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

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

View raw message