Hi Frank, On Dec 18, 2007, at 3:28 PM, Frank Barnaby wrote:
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
Ok. Just need to be aware of these files so they can be annotated.
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.
Cool.
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/NOTICEThis 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.
Ok.
4. The release bundles need to be signed with a release-signing GPG key. See http://wiki.apache.org/jdo/KeysAtApacheI'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.
The jarsigner is a different functionality from GPG signatures. If I'm not mistaken, jarsigner allows you to sign jars, while GPG allows you to sign binary files.
The GPG tool really does need to be investigated and used to sign Apache releases. GPG keys are cross-signed by other Apache release managers and the keys are part of the Apache web of trust.
Are you sure there isn't a binary of GPG available for Solaris? Craig
I plan to post a new set of release-candidate bundles tomorrow, so please post your comments as soon as possible.Frank
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
