Re: [VOTE] Release Shale version 1.0.4
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
ApacheCon (was: Release ...)
On 1/4/07, Sean Schofield [EMAIL PROTECTED] wrote: 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) snip/ No such sorries are ever needed, IMO. Talking of Amsterdam, anyone else going? Any Shale sessions planned? I have been thinking about a piece on dialogs (and maybe other things), but have made no effort towards anything ApacheCon yet. -Rahul Sean
Re: ApacheCon (was: Release ...)
Talking of Amsterdam, anyone else going? Any Shale sessions planned? I have been thinking about a piece on dialogs (and maybe other things), but have made no effort towards anything ApacheCon yet. I am going there, submitted talks on myfaces and trinidad; but nothing on shale. -M -Rahul Sean -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [FWD: [v1.0.4] shale-tiles and release notes (was Re: svn commit: r490857 ...)]
On 1/4/07, Gregg Leichtman [EMAIL PROTECTED] wrote: In that case, to avoid duplicating information, what about putting a one sentence blurb in the release notes referencing that file and the version information it contains? snip/ Its also available on the website, the dependency page for shale-tiles is here: http://shale.apache.org/shale-tiles/dependencies.html (similarly for other modules -- for each module, the 'Project Documentation' section in the left side navbar has this, and other, information). You are correct that this is easier to find for those familiar with Maven (since it generates the site). Additionally, note that the framework distribution (nightlies or release) contains all dependency jars in the lib folder, if you inspect it, you will find the jar you need, which is, in this case: tiles-core-2.0-r468346-SNAPSHOT.jar -Rahul Due to my inexperience with Maven, I would not have known to look in that location for version info. -= Gregg =- [EMAIL PROTECTED] wrote: Hi These are listed in the various profiles in the Maven POM file. Hermod -Original Message- From: Gregg Leichtman [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 03, 2007 12:56 PM To: dev@shale.apache.org Subject: Re: [FWD: [v1.0.4] shale-tiles and release notes (was Re: svn commit: r490857 ...)] Just a suggestion. It would be helpful, to me at least, if you were to include within the release notes one or more snapshot version numbers of standalone Tiles, one or more version numbers of Spring and one or more version numbers of other targeted components that work with Shale with which you the development group believes v1.0.4 appears to work. I realize that items like Tiles in sandboxes are fast moving targets, but it helps us users avoid having to do a lot of trial and error just to find a single combination of components that works. If we have one working set, substituting different components one at a time using trial and error during component upgrades is far less burdensome that not knowing anything about what works together. -= Gregg =- Rahul Akolkar wrote: On 12/29/06, Greg Reddin [EMAIL PROTECTED] wrote: From: Rahul Akolkar [EMAIL PROTECTED] Date: Thu, December 28, 2006 4:56 pm To: commits@shale.apache.org The above projected quality paragraph needs to be updated to reflect the current sentiment. Of the two items in that list, 1.0.4 will address most of the dialog issues (so I've removed that). Someone more familiar with shale-tiles (and changes implied by going TLP) should update the above paragraph in the release notes. TIA. The TLP hasn't changed the status of Tiles just yet. Tiles will still be a snapshot for a while because it will take some time to get the TLP infrastructure set up. snip/ Thanks, the related bits are in section 1 and 4 of the release notes -- you're welcome (as is everyone else) to tweak the wording (long, possibly fragmented URL): http://svn.apache.org/repos/asf/shale/framework/trunk/src/site/resources/docs/release-notes-1.0.4.html -Rahul Greg * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that the DnB NOR Group cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the anti virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: ApacheCon (was: Release ...)
On 1/4/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 1/4/07, Sean Schofield [EMAIL PROTECTED] wrote: 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) snip/ No such sorries are ever needed, IMO. Talking of Amsterdam, anyone else going? Any Shale sessions planned? I have been thinking about a piece on dialogs (and maybe other things), but have made no effort towards anything ApacheCon yet. I've submitted repeats on the two Shale sessions that Gary and I collaborated on for ApacheCon US ... a basic Shale session plus one on Shale+JPA. It would be great to see something else happen too, since the call for papers is still open for another couple weeks. The only negative for me is this is the week before JavaOne (always the madhouse activity peak of my yearly schedule). Oh well, I can always sleep in June :-). -Rahul Sean Craig
Re: [VOTE] Release Shale version 1.0.4
On 1/5/07, Craig McClanahan [EMAIL PROTECTED] 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
On 1/4/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 1/5/07, Craig McClanahan [EMAIL PROTECTED] 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
