shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <craig...@apache.org>
Subject Re: Test Maven2 Artifacts for 1.0.3 Release Available
Date Sat, 19 Aug 2006 06:01:55 GMT
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 <rahul.akolkar@gmail.com> wrote:
>
> Comments inline (contain long, potentially broken URLs) -
>
> On 8/15/06, Craig McClanahan <craigmcc@apache.org> 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.
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message