shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject Re: Test Maven2 Artifacts for 1.0.3 Release Available
Date Wed, 23 Aug 2006 19:53:46 GMT
On 8/19/06, Craig McClanahan <> wrote:
> 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.)

Thanks for the fixes and clarifications. Couple of comments below
(everything I really cared about has already been fixed).

> * Cruft in following (such as the
> > org.apache.shale.tiles.TilesViewHandler section) should be removed:
> >
> >
> > $shale-core/src/main/resources/org/apache/shale/resources/
> 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.

Agreed, I was relying on a grep in shale-core and the fact that
shale-tiles is its own artifact.

> If possible, it would be great if applicable Shale jars' manifests
> > also adopt the Jakarta Commons non-standard attributes regarding JVM
> > targets (m1 docs):
> >
> >
> >
> > 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).

Correct. The reason we adopted the manifest approach (additionally) in
Jakarta Commons was to allow users such as me to be lazier (rather
than go find the POM or for m1 builds). It appears
that m2 additionally packages these in the jars themselves in
META-INF/maven, so this should no longer be necessary.


View raw message