Robert-
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 <[EMAIL PROTECTED]> 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 (http://incubator.apache.org/incubation/
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 (http://cwiki.apache.org/openjpa/
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) --
http://incubator.apache.org/projects/openjpa.html 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 http://www.apache.org/legal/src-headers.html now asks that apache
collective copyright is included) but their licenses are not included
in LICENSE.txt. see
http://incubator.apache.org/guides/examples/LICENSE 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 https://svn.apache.org/repos/asf/incubator/
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 http://www.apache.org/legal/src-
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 --
http://svn.apache.org/repos/asf/incubator/openjpa/tags/0.9.6-
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://
www.apache.org/legal/src-headers.html#faq-binaries , 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)
http://svn.apache.org/repos/asf/incubator/openjpa/tags/0.9.6-
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.
http://svn.apache.org/repos/asf/incubator/openjpa/tags/0.9.6-
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
http://java.sun.com/xml/ns/persistence/orm_1_0.xsd 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
