Thanks for the detailed review! Responses inline, in preparation for a second round of test uploads. (I also filed issue SHALE-257 to track the individual commits made in response to these comments.)
On 8/15/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
Comments inline (contain long, potentially broken URLs) - On 8/15/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > I ran out of time tonight to create all the release artifacts we're going to > want for a 1.0.3 release (I have a flight at 6:45am tomorrow morning, and > recent events mean I have to get up a lot earlier than usual to make that > flight). However, the following 1.0.3 labelled artifacts have been > published to the Apache Snapshots repository ( > http://www/people.apache.org/repo/m2-snapshot-repository) for evaluation and > testing purposes: <snip/> Correction to the URL above: http://people.apache.org/repo/m2-snapshot-repository/ > > org.apache.shale:shale-apps-parent:1.0.3 > org.apache.shale:shale-clay:1.0.3 > org.apache.shale:shale-core:1.0.3 <snap/> * Contains a bogus manifest in jar basedir. This file should be removed: $shale-core/src/main/resources/MANIFEST.MF
Removed. * Should not contain the remoting dir (neither the Bundle.properties
therein). This directory should be removed: $shale-core/src/main/resources/org/apache/shale/remoting/
Removed. There were also some corresponding src/test/resources files that were removed. * Cruft in following Bundle.properties (such as the
org.apache.shale.tiles.TilesViewHandler section) should be removed: $shale-core/src/main/resources/org/apache/shale/resources/Bundle.properties
Not addressed this time around ... I don't have any automated tools to validate what bundle keys are actually used, and don't want to disrupt things at this point in time. * <OT>Does Studio Creator need files in jar basedir, or will some dir
in META-INF do?</OT>
No ... it wants a separate JAR containing design time classes, and a packaging JAR (called a "complib") that combines the runtime code, designtime code, sources, and javadocs. I've removed the "*complib*" and "*COMPLIB*" cruft from shale-core -- the necessary stuff will ultimately appear in the shale-designtime module, which is *not* part of 1.0.3.
org.apache.shale:shale-dist:1.0.3 <snip/> I can only find 1.0.3-SNAPSHOT
Fixed. There is now a 1.0.3 version deployed on the snapshot repository.
org.apache.shale:shale-master:1.0.3 <snap/> Did you mean org.apache.shale:shale-master:1 ?
Yes ... sorry.
org.apache.shale:shale-parent:1.0.3 <snip/> maven-javadoc-plugin dependency version numbers inconsistent with dependencies section (digester points to 1.6, should be 1.7 and logging points to 1.0.4, should be 1.1)
Fixed, and added a couple of pointers to more commons javadocs.
org.apache.shale:shale-remoting:1.0.3 > org.apache.shale:shale-spring:1.0.3 > org.apache.shale:shale-test:1.0.3 <snap/> No LICENSE, NOTICE in jar. Move LICENSE.txt and NOTICE.txt from: $shale-test/ to $shale-test/src/main/resources
Fixed for all framework libraries. The files had been moved to src/main/resources in most cases already ... but they really needed to be in src/main/resources/META-INF.
org.apache.shale:shale-tiger:1.0.3 > org.apache.shale:shale-tiles:1.0.3 <snip/> No LICENSE, NOTICE in jar. Move LICENSE.txt and NOTICE.txt from: $shale-tiles/ to $shale-tiles/src/main/resources
Same as above. If possible, it would be great if applicable Shale jars' manifests
also adopt the Jakarta Commons non-standard attributes regarding JVM targets (m1 docs): http://jakarta.apache.org/commons/releases/prepare.html#checkjarmanifest More of a reassurance, than anything else, for those of us having deployments on 1.4.
Maven 2 generated MANIFEST.MF files include a "Build-Jdk" header to document what was used to actually build this jar, but it's not going to be particularly reassuring :-). It says "1.5.0_07" in every case, because that is the JDK used to create the entire build (so that it would build the 1.5dependent stuff too). An examination of the POMs, however, will show you that the source and target levels default to 1.4, and are only set to 1.5 on the things that depend on that (shale-tiger, shale-sql-browser, mailreader-jpa, and shale-mailreader-jpa). Finally, thanks to all for the work towards Shale 1.0.3. And thanks for taking the time to review the test results. See a following message for an updated set of test uploads. -Rahul Craig
> Before we can vote on this, I need to publish the proposed .tar.gz and .zip > distributions for the framework itself, and all of the example applications > (essentially equivalent to what we publish in the nightly builds process). > But I wanted to give committers a head start on helping me verify the > content of the release. To try it out, simply change the version dependency > of one of your test applications from 1.0.3-SNAPSHOT to 1.0.03 itself, and > report results back to the dev list. > > Craig > > PS: Please hold up on commits to the repository unless you intend that the > update be included in the 1.0.3 release. The POMS are all set that way, and > I don't want to update them to 1.0.4-SNAPSHOT until the test release process > is completed. > >
