On Dec 12, 2007, at 15:57, Craig L Russell wrote:
Ok, here's the result from running the RAT.
A couple of comments:
0. Nice to see the release activity here.
1. Generally, files that *can* contain license information *should*
contain license information (this means not just .java files but
other text files (css files, properties files config files) as
well). Files that don't support comments at all are ok, but need
more work by the release manager because RAT will flag them.
The css files are generated by the javadoc process, which is based on
the style sheet built into the javadoc tool. The javadoc tool does
have an option to specify a different style sheet, into which we could
add a license header; however, that would force us to start
maintaining style sheets, and I don't think it's necessary to add a
license header to the javadoc style sheets. Unless someone has a
compelling reason to the contrary, I'm not planning on adding a
license header to the javadoc style sheets.
The following files also will not contain license headers because I
the files do not support comments:
doc/j2se/package-list
src/manifest/*.mf
src/com/sun/jini/example/hello/prebuiltkeys/*.password
I have, on the other hand, added a license header to the following
files:
doc/specs/html/serviceui-spec.html
src/com/sun/jini/example/hello/config/*.config
src/com/sun/jini/example/hello/config/*.policy
src/com/sun/jini/phoenix/resources/*.properties
src/com/sun/jini/start/resources/*.properties
src/com/sun/jini/tool/.../*.properties
src/configentry/*
src/manifest/*/META-INF/PREFERRED.LIST
src/manifest/*/META-INF/services/*
So, the RAT output is now much cleaner.
2. It seems there are some extraneous files here (apache-river-2.1.1/
source/src/ff, e-river-2.1.1/source/src/ff2.out)
Removed.
3. Some of the NOTICE files appear to be in the wrong place. apache-
river-2.1.1/doc/api/doc-files/NOTICE
This NOTICE file is linked within the footers of the api javadoc to
allow the javadoc to be used standalone. This NOTICE file is also
just a copy of the NOTICE file in the top-level of the release
distribution, which is the proper location for that file. Therefore,
this NOTICE file will remain in its current location.
4. The release bundles need to be signed with a release-signing GPG
key. See http://wiki.apache.org/jdo/KeysAtApache
I've been working on this task. I had planned on using GNU Privacy
Guard (GPG) to sign the bundles, but building GPG and its dependent
libraries proved to be a problem on Solaris (libassuan in particular),
so I'm considering jarsigner and keytool, which are included in the
JDK and readily accessible to all. Please let me know if there's any
reason why I should avoid jarsigner or, alternatively, why I should
strive to utilize GPG.
I plan to post a new set of release-candidate bundles tomorrow, so
please post your comments as soon as possible.
Frank
