river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Barnaby <Frank.Barn...@Sun.COM>
Subject Re: "AR1" testing
Date Tue, 18 Dec 2007 23:28:21 GMT

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:


I have, on the other hand, added a license header to the following  


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)


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


View raw message