You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shale.apache.org by Rahul Akolkar <ra...@gmail.com> on 2007/01/03 02:10:26 UTC
[VOTE] Release Shale version 1.0.4
This is a vote to release Apache Shale version 1.0.4
(1) The repository has been tagged (long, possibly fragmented URLs below):
http://svn.apache.org/repos/asf/shale/framework/tags/APACHE_SHALE_1_0_4/
(2) The Maven artifacts are staged:
http://people.apache.org/~rahul/shale/v104/repos
org.apache.shale.extras:mailreader-jpa:1.0.4
org.apache.shale:shale-application:1.0.4
org.apache.shale:shale-apps-parent:1.0.4
org.apache.shale:shale-clay:1.0.4
org.apache.shale:shale-core:1.0.4
org.apache.shale:shale-dialog:1.0.4
org.apache.shale:shale-dialog-basic:1.0.4
org.apache.shale:shale-dialog-scxml:1.0.4
org.apache.shale:shale-dist:1.0.4
org.apache.shale:shale-parent:1.0.4
org.apache.shale:shale-remoting:1.0.4
org.apache.shale:shale-spring:1.0.4
org.apache.shale:shale-test:1.0.4
org.apache.shale:shale-tiger:1.0.4
org.apache.shale:shale-tiles:1.0.4
org.apache.shale:shale-validator:1.0.4
org.apache.shale:shale-view:1.0.4
(3) The release artifacts are available:
http://people.apache.org/~rahul/shale/v104/
mailreader-jpa-1.0.4.zip
shale-blank-1.0.4.zip
shale-clay-usecases-1.0.4.zip
shale-framework-1.0.4.zip
shale-mailreader-1.0.4.zip
shale-mailreader-jpa-1.0.4.zip
shale-sql-browser-1.0.4.zip
shale-usecases-1.0.4.zip
(4) The release notes are here, for ready reference:
http://people.apache.org/~rahul/shale/v104/release-notes-1.0.4.html
(5) Vote
Please review these artifacts, signatures and checksums, and vote
whether we should release them as Apache Shale version 1.0.4.
--8<--------------------------------------------
[ ] +1 (Binding) for PMC members only
[ ] +1 for community members who have reviewed the bits
[ ] +0
[ ] -1 for fatal flaws that should cause these bits not to be released
------------------------------------------------
A quality vote (per module, where necessary) will be held later on if
this passes.
-Rahul
Re: [VOTE] Release Shale version 1.0.4
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/3/07, Craig McClanahan <cr...@apache.org> wrote:
<snip/>
>
> * The sample apps have the version number in their archive names,
> but the embedded directory, and the name of the WAR file inside,
> does not. Looking at the entire release, I have a mild preference for
> including the version number everywhere it's relevant.
>
<snap/>
Agreed. FWIW, I had a medium preference (> mild) but m2 wasn't doing
it for me. Need to figure out how to appease it.
> * The NOTICE.txt files all contain the attribution to David Geary and
> Cay Horstmann for the code originally published in Core JavaServer Faces.
> This was exactly correct up to 1.0.3, but when we split everything up, I
> *think* the only module that actually contains such code is the
> shale-validator module (and we'd also want the attribution in the top
> level
> framework notice as well). That will need to be researched before we
> change anything, though.
>
<snip/>
We should open a JIRA issue against 1.0.5-SNAP for this. I'll do it
when I conclude the vote (if its not there by then).
> * In addition to not publishing the POMs for shale-master and shale-apps
> in a standalone artifact (see previous discussion in this thread), we are
> also not publishing the sources to the top level website. That's OK since
> they are accessible via SVN, but we should include these files in any
> discussion of what to do about the POMs.
>
<snap/>
You mean what we see at http://shale.apache.org/ ? Those sources are
there, in the framework zip, under src/site.
-Rahul
> Craig
>
>
Re: [VOTE] Release Shale version 1.0.4
Posted by Sean Schofield <se...@gmail.com>.
> Thanks to Rahul for all the grunt work to pull this release together!
+1 for that sentiment!
Sorry I haven't been much help lately. I'm just getting my business
off the ground these days so I've been tied up with that and some
family stuff. I will be following along the best I can for the next
couple of months! (And I will see some of you in Amsterdam)
Sean
Re: [VOTE] Release Shale version 1.0.4
Posted by Craig McClanahan <cr...@apache.org>.
On 1/2/07, Rahul Akolkar <ra...@gmail.com> wrote:
>
>
> Please review these artifacts, signatures and checksums, and vote
> whether we should release them as Apache Shale version 1.0.4.
>
> --8<--------------------------------------------
> [X] +1 (Binding) for PMC members only
> [ ] +1 for community members who have reviewed the bits
> [ ] +0
> [ ] -1 for fatal flaws that should cause these bits not to be released
> ------------------------------------------------
Thanks to Rahul for all the grunt work to pull this release together! I
have been through it with a medium-to-fine grained comb :-), and cannot find
any showstopper issues. That being said, here's some notes for us to think
about in the future:
* The sample apps have the version number in their archive names,
but the embedded directory, and the name of the WAR file inside,
does not. Looking at the entire release, I have a mild preference for
including the version number everywhere it's relevant.
* The NOTICE.txt files all contain the attribution to David Geary and
Cay Horstmann for the code originally published in Core JavaServer Faces.
This was exactly correct up to 1.0.3, but when we split everything up, I
*think* the only module that actually contains such code is the
shale-validator module (and we'd also want the attribution in the top
level
framework notice as well). That will need to be researched before we
change anything, though.
* In addition to not publishing the POMs for shale-master and shale-apps
in a standalone artifact (see previous discussion in this thread), we are
also not publishing the sources to the top level website. That's OK since
they are accessible via SVN, but we should include these files in any
discussion of what to do about the POMs.
Craig
Re: [VOTE] Release Shale version 1.0.4
Posted by Craig McClanahan <cr...@apache.org>.
On 1/4/07, Rahul Akolkar <ra...@gmail.com> wrote:
>
> On 1/5/07, Craig McClanahan <cr...@apache.org> wrote:
> <snip/>
> >
> > What should also happen here is attribution in the NOTICE.txt file for
> > shale-tiger module too ... I'll look into the appropriate wording for
> that
> > and commit something soon.
> >
> <snap/>
>
> OK, I will be cutting the new artifacts in ~8 hours (I'll be away this
> weekend and would like to get the vote going before that).
Wow ... you get up early :-)
The mystery deepens a bit as I'm looking at the CVS logs for these files. A
CDDL header was added (by a standard "add licenses before we open source"
sweep to both DTDs in August 2005, but was explicitly removed by a separate
commit in March 2006. I'm not going to be able to resolve that before you
disappear for the weekend, but I know that these DTDs were *intended* to be
redistributable. It's just that there is no way to know if a copyright
attribution is appropriate, since there is no copyright statement in the
files themselves.
What I'd suggest we do for 1.0.4 is go ahead and fix everything else, but do
nothing explicit about these two files. There is ample precedent at Apache
for publishing them as part of a release, and if need be I can fall on my
sword within Sun if there are any issues -- but I'm sure there will not be
any ... the whole point of open sourcing the RIs (including the API stuff,
which includes the DTDs) was to eliminate barriers to *using* these kinds of
artifacts.
> Craig
> >
> > PS: Rahul, don't forget to apply your cleanups based on Niall's
> comments to
> > the trunk too. Otherwise, we'll need to go through this exercise again
> next
> > time :-).
> >
> <snip/>
>
> Yup, will do (I agree its best to do this immediately, for some reason
> I felt like porting the release related tweaks in one shot at the end
> ;-).
As long as they get included, I'm fine on the timing :-)
> PPS: I'm also +1 on removing the Cobertura reports from the release
> > version, although I do find the reports useful during development
> cycles.
> >
> >
>
> Tempted towards a "dev" profile for pushing out all reports
> (Cobertura, PMD, CPD, Checkstyle and what not) -- so (a) we don't get
> caught up in trying to sanitize all the bits these reports generate in
> the release distros and (b) its possible to generate a light version
> of the site for the documentation (but not reporting) bits.
I can see that POV ... and as long as we can convince Continuum to use the
"dev" profile on its continuous build runs, I'm fine. The important thing
to me is that the coverage reports (in the case of this particular plugin)
are available to developers on a "continuous" basis.
Does publishing a GPL'd javascript file, on the Apache Shale website (but
not part of a downloadable artifact), cause a problem with the standard
"distribution" policy of what we can include in an artifact? Nah ... it's
too late in the evening today for me to want to go there :-).
-Rahul
>
Craig
Re: [VOTE] Release Shale version 1.0.4
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/5/07, Craig McClanahan <cr...@apache.org> wrote:
<snip/>
>
> What should also happen here is attribution in the NOTICE.txt file for
> shale-tiger module too ... I'll look into the appropriate wording for that
> and commit something soon.
>
<snap/>
OK, I will be cutting the new artifacts in ~8 hours (I'll be away this
weekend and would like to get the vote going before that).
> Craig
>
> PS: Rahul, don't forget to apply your cleanups based on Niall's comments to
> the trunk too. Otherwise, we'll need to go through this exercise again next
> time :-).
>
<snip/>
Yup, will do (I agree its best to do this immediately, for some reason
I felt like porting the release related tweaks in one shot at the end
;-).
> PPS: I'm also +1 on removing the Cobertura reports from the release
> version, although I do find the reports useful during development cycles.
>
>
Tempted towards a "dev" profile for pushing out all reports
(Cobertura, PMD, CPD, Checkstyle and what not) -- so (a) we don't get
caught up in trying to sanitize all the bits these reports generate in
the release distros and (b) its possible to generate a light version
of the site for the documentation (but not reporting) bits.
-Rahul
Re: [VOTE] Release Shale version 1.0.4
Posted by Craig McClanahan <cr...@apache.org>.
On 1/4/07, Rahul Akolkar <ra...@gmail.com> wrote:
>
> Thanks a lot for the detailed review of the distros, Niall !
>
> I will comment on specific points below, but in light of Niall's
> feedback I am proposing:
>
> a) We close this vote, and declare it unsuccessful
> b) We apply suggested fixes (again, specific comments below) and
> recreate the svn tag
> c) We vote again on new proposed artifacts with these fixes (and these
> fixes only)
>
> This means folks who have reviewed the artifacts will need to do so
> again, sorry for the inconvenience.
>
> Any objections to this plan?
Sounds reasonable.
Regarding web-facesconfig_1_0.dtd and web-facesconfig_1_1.dtd -- these two
files are available under the CDDL license as part of the JSF 1.2 source
distribution. Interestingly, the source files in the original distribution
do no have license or copyright headers (I'll forward notes about that to
the appropriate folks), but CDDL was on the acceptable compatibility list
last time I looked. If there are problems, both Struts (with the
struts-faces extension) and MyFaces will also have issues.
What should also happen here is attribution in the NOTICE.txt file for
shale-tiger module too ... I'll look into the appropriate wording for that
and commit something soon.
Craig
PS: Rahul, don't forget to apply your cleanups based on Niall's comments to
the trunk too. Otherwise, we'll need to go through this exercise again next
time :-).
PPS: I'm also +1 on removing the Cobertura reports from the release
version, although I do find the reports useful during development cycles.
Re: [VOTE] Release Shale version 1.0.4
Posted by Rahul Akolkar <ra...@gmail.com>.
Thanks a lot for the detailed review of the distros, Niall !
I will comment on specific points below, but in light of Niall's
feedback I am proposing:
a) We close this vote, and declare it unsuccessful
b) We apply suggested fixes (again, specific comments below) and
recreate the svn tag
c) We vote again on new proposed artifacts with these fixes (and these
fixes only)
This means folks who have reviewed the artifacts will need to do so
again, sorry for the inconvenience.
Any objections to this plan?
On 1/4/07, Niall Pemberton <ni...@gmail.com> wrote:
> I just noticed another thing - theres some JavaScript files which are
> being distributed as part of the Cobertura documentation
> (sortabletable.js, stringbuilder.js and customsorttypes.js) which
> have two different licenses (GPL, plus others). Looks to me like there
> should at least be an attribution in the NOTICE.txt - at a minimum I
> think you need to review whether its OK to re-distribute these since
> users will be using that software if they look at the Cobertura
> documentation. IMO it would be better if they were excluded from the
> distros altogether.
>
<snip/>
OK, with that information, IMO, we should remove the cobertura plugin
completely for v1.0.4. We can discuss a suitable test coverage plugin
to add later, but as things stand, it seems to be mostly broken
[1],[2] in the current build anyway (we do have some tests for these
modules actually, contrary to what these report says).
[1] http://shale.apache.org/shale-core/cobertura/index.html
[2] http://shale.apache.org/shale-clay/cobertura/index.html
(more comments below ...)
> Niall
>
> On 1/4/07, Niall Pemberton <ni...@gmail.com> wrote:
> > A couple of nitpicks
> >
> > 1) I ran the rat tool on the framework distro, after removing the docs
> > directory (which highlighted a load of generated files) there were a
> > few missing license headers. Patch available here:
> > https://issues.apache.org/struts/browse/SHALE-384
> >
<snap/>
I will fix this (assigned SHALE-384 to me already).
> > Also there are two Sun licensed files included in the distro in
> > shale-tiger's resources:
> > web-facesconfig_1_0.dtd
> > web-facesconfig_1_1.dtd
> >
> > Are we authorised to re-distribute these files?
> >
<snip/>
Craig is probably the best person here to answer this (though others
may know as well).
> > 2) None of the shale jar files contain the usual manifest entries such as:
> > Extension-Name
> > Specification-Title
> > Specification-Vendor
> > Specification-Version
> > Implementation-Title
> > Implementation-Vendor
> > Implementation-Version
> > Implementation-Vendor-Id
> >
> > I've attached a patch for the pom to include these to the above JIRA ticket
> >
<snap/>
I maintained the inertia from previous releases regarding the
manifests, in hindsight, shouldn't have. Thanks again for all the
patches Niall.
-Rahul
> > Niall
> >
<snip/>
Re: [VOTE] Release Shale version 1.0.4
Posted by Niall Pemberton <ni...@gmail.com>.
I just noticed another thing - theres some JavaScript files which are
being distributed as part of the Cobertura documentation
(sortabletable.js, stringbuilder.js and customsorttypes.js) which
have two different licenses (GPL, plus others). Looks to me like there
should at least be an attribution in the NOTICE.txt - at a minimum I
think you need to review whether its OK to re-distribute these since
users will be using that software if they look at the Cobertura
documentation. IMO it would be better if they were excluded from the
distros altogether.
Niall
On 1/4/07, Niall Pemberton <ni...@gmail.com> wrote:
> A couple of nitpicks
>
> 1) I ran the rat tool on the framework distro, after removing the docs
> directory (which highlighted a load of generated files) there were a
> few missing license headers. Patch available here:
> https://issues.apache.org/struts/browse/SHALE-384
>
> Also there are two Sun licensed files included in the distro in
> shale-tiger's resources:
> web-facesconfig_1_0.dtd
> web-facesconfig_1_1.dtd
>
> Are we authorised to re-distribute these files?
>
> 2) None of the shale jar files contain the usual manifest entries such as:
> Extension-Name
> Specification-Title
> Specification-Vendor
> Specification-Version
> Implementation-Title
> Implementation-Vendor
> Implementation-Version
> Implementation-Vendor-Id
>
> I've attached a patch for the pom to include these to the above JIRA ticket
>
> Niall
>
>
> On 1/3/07, Rahul Akolkar <ra...@gmail.com> wrote:
> > This is a vote to release Apache Shale version 1.0.4
> >
> > (1) The repository has been tagged (long, possibly fragmented URLs below):
> >
> > http://svn.apache.org/repos/asf/shale/framework/tags/APACHE_SHALE_1_0_4/
> >
> > (2) The Maven artifacts are staged:
> >
> > http://people.apache.org/~rahul/shale/v104/repos
> >
> > org.apache.shale.extras:mailreader-jpa:1.0.4
> > org.apache.shale:shale-application:1.0.4
> > org.apache.shale:shale-apps-parent:1.0.4
> > org.apache.shale:shale-clay:1.0.4
> > org.apache.shale:shale-core:1.0.4
> > org.apache.shale:shale-dialog:1.0.4
> > org.apache.shale:shale-dialog-basic:1.0.4
> > org.apache.shale:shale-dialog-scxml:1.0.4
> > org.apache.shale:shale-dist:1.0.4
> > org.apache.shale:shale-parent:1.0.4
> > org.apache.shale:shale-remoting:1.0.4
> > org.apache.shale:shale-spring:1.0.4
> > org.apache.shale:shale-test:1.0.4
> > org.apache.shale:shale-tiger:1.0.4
> > org.apache.shale:shale-tiles:1.0.4
> > org.apache.shale:shale-validator:1.0.4
> > org.apache.shale:shale-view:1.0.4
> >
> > (3) The release artifacts are available:
> >
> > http://people.apache.org/~rahul/shale/v104/
> >
> > mailreader-jpa-1.0.4.zip
> > shale-blank-1.0.4.zip
> > shale-clay-usecases-1.0.4.zip
> > shale-framework-1.0.4.zip
> > shale-mailreader-1.0.4.zip
> > shale-mailreader-jpa-1.0.4.zip
> > shale-sql-browser-1.0.4.zip
> > shale-usecases-1.0.4.zip
> >
> > (4) The release notes are here, for ready reference:
> >
> > http://people.apache.org/~rahul/shale/v104/release-notes-1.0.4.html
> >
> > (5) Vote
> >
> > Please review these artifacts, signatures and checksums, and vote
> > whether we should release them as Apache Shale version 1.0.4.
> >
> > --8<--------------------------------------------
> > [ ] +1 (Binding) for PMC members only
> > [ ] +1 for community members who have reviewed the bits
> > [ ] +0
> > [ ] -1 for fatal flaws that should cause these bits not to be released
> > ------------------------------------------------
> >
> > A quality vote (per module, where necessary) will be held later on if
> > this passes.
> >
> > -Rahul
>
Re: [VOTE] Release Shale version 1.0.4
Posted by Niall Pemberton <ni...@gmail.com>.
A couple of nitpicks
1) I ran the rat tool on the framework distro, after removing the docs
directory (which highlighted a load of generated files) there were a
few missing license headers. Patch available here:
https://issues.apache.org/struts/browse/SHALE-384
Also there are two Sun licensed files included in the distro in
shale-tiger's resources:
web-facesconfig_1_0.dtd
web-facesconfig_1_1.dtd
Are we authorised to re-distribute these files?
2) None of the shale jar files contain the usual manifest entries such as:
Extension-Name
Specification-Title
Specification-Vendor
Specification-Version
Implementation-Title
Implementation-Vendor
Implementation-Version
Implementation-Vendor-Id
I've attached a patch for the pom to include these to the above JIRA ticket
Niall
On 1/3/07, Rahul Akolkar <ra...@gmail.com> wrote:
> This is a vote to release Apache Shale version 1.0.4
>
> (1) The repository has been tagged (long, possibly fragmented URLs below):
>
> http://svn.apache.org/repos/asf/shale/framework/tags/APACHE_SHALE_1_0_4/
>
> (2) The Maven artifacts are staged:
>
> http://people.apache.org/~rahul/shale/v104/repos
>
> org.apache.shale.extras:mailreader-jpa:1.0.4
> org.apache.shale:shale-application:1.0.4
> org.apache.shale:shale-apps-parent:1.0.4
> org.apache.shale:shale-clay:1.0.4
> org.apache.shale:shale-core:1.0.4
> org.apache.shale:shale-dialog:1.0.4
> org.apache.shale:shale-dialog-basic:1.0.4
> org.apache.shale:shale-dialog-scxml:1.0.4
> org.apache.shale:shale-dist:1.0.4
> org.apache.shale:shale-parent:1.0.4
> org.apache.shale:shale-remoting:1.0.4
> org.apache.shale:shale-spring:1.0.4
> org.apache.shale:shale-test:1.0.4
> org.apache.shale:shale-tiger:1.0.4
> org.apache.shale:shale-tiles:1.0.4
> org.apache.shale:shale-validator:1.0.4
> org.apache.shale:shale-view:1.0.4
>
> (3) The release artifacts are available:
>
> http://people.apache.org/~rahul/shale/v104/
>
> mailreader-jpa-1.0.4.zip
> shale-blank-1.0.4.zip
> shale-clay-usecases-1.0.4.zip
> shale-framework-1.0.4.zip
> shale-mailreader-1.0.4.zip
> shale-mailreader-jpa-1.0.4.zip
> shale-sql-browser-1.0.4.zip
> shale-usecases-1.0.4.zip
>
> (4) The release notes are here, for ready reference:
>
> http://people.apache.org/~rahul/shale/v104/release-notes-1.0.4.html
>
> (5) Vote
>
> Please review these artifacts, signatures and checksums, and vote
> whether we should release them as Apache Shale version 1.0.4.
>
> --8<--------------------------------------------
> [ ] +1 (Binding) for PMC members only
> [ ] +1 for community members who have reviewed the bits
> [ ] +0
> [ ] -1 for fatal flaws that should cause these bits not to be released
> ------------------------------------------------
>
> A quality vote (per module, where necessary) will be held later on if
> this passes.
>
> -Rahul
Re: [VOTE] Release Shale version 1.0.4
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/3/07, Craig McClanahan <cr...@apache.org> wrote:
> On 1/2/07, Rahul Akolkar <ra...@gmail.com> wrote:
> >
> > org.apache.shale:shale-apps-parent:1.0.4
>
>
> As part of my review of the proposed 1.0.4 release (all the sigs match ...
> but let's see what happens when I try to *use* this stuff :-), I want to try
> building our distribution artifacts. I could build the framework with no
> problems -- but trying to build an app fails because this artifact is
> (correctly) not available in any repository yet. Thinking about it a bit
> more, we aren't officially distributing *source* artifacts for this POM, or
> for "org.apache.shale:shale-master:2" either -- both of which you would need
> to install if you're trying to build Shale. On the other hand, once the
> distribution is voted in and released, the artifacts will be available (but
> only if you know to go get them).
>
> One could certainly argue that, since our source build system is Maven
> based, we could expect this to "just work" for our downstream users after a
> release. But what about folks who are not "always on" connected to the
> Internet? Or folks who need to be able to build Shale, from source, in
> Maven's "offline" mode? Maybe we should publish these two POM artifacts as
> part of some "source distribution" somewhere, like we do all the other POMs?
>
<snip/>
A m2 bootstrap distro having shale-{master,parent,apps-parent}.pom is
a possibility (the mechanics would need fleshing out since they're not
in the same source subtree), but that is also no guarantee that a
build will just work when there is no connectivity (or for an offline
build). For example, the build may not have:
* A dependency version we need (workaround: install it manually from
shale-framework.zip/lib -- assumes that was downloaded, not just the
sample app zip)
* A plugin we need (such as gpg with -Prelease, and while its
debatable whether using the release profile is a reasonable thing to
do, there are probably better examples elsewhere)
In my experience, for any sizeable m2 build, I've had to be connected
the first time. Ofcourse, thereafter, it may be possible to work
offline. Using build tooling that has a notion of central management
of artifact metadata (for dependencies and tooling components
themselves) implies, IMO, waiving some of our expectations about
things working when that (remote) metadata is no longer accessible.
> Craig
>
> PS: I'm not done reviewing the proposed 1.0.4 bits, but things look good
> (outside of the issue raised here) so far.
>
<snap/>
No rush, please take your time.
-Rahul
Re: [VOTE] Release Shale version 1.0.4
Posted by Craig McClanahan <cr...@apache.org>.
On 1/2/07, Rahul Akolkar <ra...@gmail.com> wrote:
>
> org.apache.shale:shale-apps-parent:1.0.4
As part of my review of the proposed 1.0.4 release (all the sigs match ...
but let's see what happens when I try to *use* this stuff :-), I want to try
building our distribution artifacts. I could build the framework with no
problems -- but trying to build an app fails because this artifact is
(correctly) not available in any repository yet. Thinking about it a bit
more, we aren't officially distributing *source* artifacts for this POM, or
for "org.apache.shale:shale-master:2" either -- both of which you would need
to install if you're trying to build Shale. On the other hand, once the
distribution is voted in and released, the artifacts will be available (but
only if you know to go get them).
One could certainly argue that, since our source build system is Maven
based, we could expect this to "just work" for our downstream users after a
release. But what about folks who are not "always on" connected to the
Internet? Or folks who need to be able to build Shale, from source, in
Maven's "offline" mode? Maybe we should publish these two POM artifacts as
part of some "source distribution" somewhere, like we do all the other POMs?
Craig
PS: I'm not done reviewing the proposed 1.0.4 bits, but things look good
(outside of the issue raised here) so far.