[Announce] Call For Papers opens for ApacheCon US 2009
-- Forwarded message -- From: William A. Rowe, Jr. [EMAIL PROTECTED] If you have only 30 seconds to read this; Join us in celebrating the ASF's 10th Anniversary at ApacheCon! The Call for Papers is now open for ApacheCon US 2009, taking place 2-6 November in Oakland, California. Proposals are being accepted at http://us.apachecon.com/c/acus2009/cfp/ and can be revised at anytime until the submissions closing deadline of 28 February 2009. In addition, sponsorship opportunities for both ApacheCon EU 2009/Amsterdam and ApacheCon US 2009/Oakland are available. Please contact Delia Frees at [EMAIL PROTECTED] for further information. Please, read on... *** ApacheCon Celebrates the ASF's 10th Anniversary in Oakland, California, 2-6 November 2009 Call for Papers Opens for ApacheCon US 2009 The Apache Software Foundation (ASF) invites submissions to its official user and developer conference, taking place 2-6 November 2009 at the Oakland Convention Center and Marriott Hotel. ApacheCon serves as a forum for showcasing the ASF's latest projects, members, and community initiatives. Offering unparalleled educational opportunities, ApacheCon's presentations, hands-on trainings, and sessions address key technology, development, business/community, and licensing issues in Open Source. The wide range of activities offered at ApacheCon promotes the exchange of ideas amongst ASF Members, committers, innovators, developers, vendors, and users interested in the future of Open Source technology. The conference program includes peer-reviewed sessions, trainings/workshops, and select invited keynote presentations and speakers. Conference Themes and Topics Building on ten years of success, ApacheCon returns to the Bay Area for the 10th anniversary of the Apache Software Foundation. Comprising some of the most active and recognized developers in the Open Source community, ApacheCon provides an influential platform for dialogue between Open Source developers and users, traversing a wide range of ideas, expertise, and personalities. ApacheCon welcomes submissions across many fields, geographic locations, and areas of development. The breadth of the Apache community lends itself to conference content that is somewhat loosely-structured, with common themes of interest addressing groundbreaking technologies and emerging trends, best practices (from development to deployment), case studies and lessons learned (tips, tools, and tricks). In addition, ApacheCon will continue to offer its highly popular, two-day intensive trainings; certifications of completion will be distributed to those who fulfill all the training requirements. Topics appropriate for submission are manifold, and may include but are not restricted to: Apache HTTP server (installation, configuration, migration, and more); ASF-wide projects (including Lucene, Hadoop, Jackrabbit, and Maven); Scripting languages and dynamic content (such as Java, Perl, Python, Ruby, XSL, and PHP); Security and e-commerce (performance tuning, load balancing and high availability); New technologies (including broader initiatives such as Web Services and Web 2.0); ASF-Incubated projects (such as Sling, UIMA, and Shindig); and Business/Community issues (Open Source driven business models, open development, enterprise adoption, and more). Submission Guidelines Submissions must include; – Session title - Speaker name - Speaker biography - Session description - Format and duration - Audience expertise level Full details are available online on the CFP page at [WWW] http://us.apachecon.com/c/acus2009/cfp/ Types of Presentations; - Trainings/Workshops - General Sessions - Case Studies/Industry Profiles - Corporate Showcases Demonstrations - Fast Feather (short) sessions - Birds of a Feather discussions - Invited Keynotes/Panels/Speakers Pre-Conference Trainings/Workshops Held on the first two days of the conference (2-3 November 2009), ApacheCon trainings are available at a registration fee beyond the regular conference fee. Proposals may be submitted for half-day (3 hours), full-day (6 hours), or two-day (12 hours) training sessions. These proposed tutorials should be aimed at providing in-depth, hands-on development experience or related continuing education. Training submissions are welcome at beginner, intermediate, and expert levels. General Sessions include presentations on practical development applications, insight into high-interest projects, best practices and key advances, overcoming implementation challenges, and industry innovations. Especially welcome are submissions that extend participants' understanding the role of ASF projects and their influence on the Open Source community at large. General Sessions are scheduled for 50 minutes and are accessible to all conference delegates. Case Study/Industry Profile Practitioners are invited to submit presentations that focus on how implementing particular ASF technologies led to improved
Re: Shale Test
On Tue, Sep 30, 2008 at 11:23 AM, Greg Reddin [EMAIL PROTECTED] wrote: On Mon, Sep 29, 2008 at 6:22 PM, Kito Mann [EMAIL PROTECTED] wrote: That's fine, but I don't really see _anyone_ driving releases :-). What's the problem with letting Shale Test move somewhere else? The problem, though, is that Shale Test is part of a project that has stagnated. So, even if Shale Test moves forward, it's difficult to get traction if the whole project is perceived as stale. Do you see what I'm saying? If there are so many people out there who want to help move Shale Test forward, then we would love for them to step up and start contributing. snip/ +1 to this and the bits below (and thanks to Greg for his patience in writing thoughtful responses :-). -Rahul Look at it this way: I use Shale in at least one project at work, so I have a vested interest in it continuing to work. Now a whole bunch of people from Project Foo think Shale needs to move forward and that it can move forward better over at Project Foo. But I've never seen code from the folks at Project Foo. I don't know their attitudes or development styles. I don't know how they work with others. I don't know if they will release it under a license I am comfortable with. How can I agree in good faith to just hand over the management of Shale to Project Foo when I don't know these things? We are commissioned by the ASF to manage the Shale project. You could make a decent argument that we have not done a very good job of managing the project. But we cannot recommend to the ASF in good faith that the best direction for the project is to send it to somebody else who we don't know. So that brings us back to this: If people think Shale Test needs to move forward then I would cordially and sincerely invite them to come join the dev list and start submitting patches. Point me to the patches that have not been responded to. Point me to the questions and requests that are not being answered. When I see that I can begin to give credibility to your argument that Shale would be better managed elsewhere. Just so I am clear: the motive of this post is not to be dramatic or troll or anything like that. I want to see Shale move forward too. If the best thing is for it to move elsewhere, then I will be the first to vote for that. But I can't trust who I don't know. Send those folks over here and let's engage in some discussion and get some stuff done. Thanks, Greg
Re: Shale Website
On Fri, Jul 25, 2008 at 11:27 AM, Greg Reddin [EMAIL PROTECTED] wrote: Where's the best place to manage the site? I noticed that the site source in the trunk is different from that in the 1_0_X branch. I was trying to get the site ready to deploy now that 1.0.5 is finished and before I make an announcement. But I'm not sure whether to deploy the trunk site or the branch site. I'm guessing I should modify and deploy the trunk, correct? snip/ Both, I'd think. So, for example, after the 1.0.4 release, the 1.0.4 site was deployed here: http://shale.apache.org/1.0.4/ This is useful because it allows us to point to release documentation (as against, latest documentation). So it'd be great to have http://shale.apache.org/1.0.5/ from the 1.0.5 tag and also update http://shale.apache.org/ from trunk (with the home page download section updated to point to 1.0.5 as the current release, and other changes as necessary). -Rahul Thanks, Greg
Re: [VOTE] Release Shale 1.0.5
On 6/2/08, Greg Reddin [EMAIL PROTECTED] wrote: A set of artifacts for Shale 1.0.5 is now ready. Please review the artifacts mentioned below and vote accordingly. Since this is my first time as release manager I wouldn't be surprised if something is missing or if I've included things that shouldn't be included, so I'd appreciate as thorough a review as you have time for. In particular I see a lot of Maven artifacts and zip files that were not included in previous releases so I wonder if they are meant to be release (the *test* artifacts for example). snip/ Thanks for putting the bits together Greg! Two high-level comments: 1) The *test* artifacts aren't meant to be distributed via releases, or used for anything beyond local testing, IIRC. (the usecases apps are meant to demo features). I would prefer we leave them out, to avoid many differences in this point release. You should be able to just blow those *test* directories / artifacts away in the m2 staging repo / dist area. 2) In the ballot below, can you please revise the first couple of lines to read ... [ ] +1 for beta release (Binding, PMC members only) [ ] +1 for beta release (community members who have reviewed the bits) ... or some such. The important bit is to note the initial quality as beta. This is one of the things I did not do when posting the CfV for v1.0.4 (and we had to clarify that in a separate thread later). This way the release announcement can state the initial quality to be beta (and that it will potentially be revised later). Also, I think we can even do away with the PMC / otherwise distinction in the ballot. I'll leave that to you. These changes are fairly superficial, so shouldn't require any rebuilding (and this vote thread can continue, IMO). -Rahul (5) Vote Please review these artifacts, signatures and checksums, and vote whether we should release them as Apache Shale version 1.0.5. --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. Thank you!! Greg
Re: [VOTE] Release Shale 1.0.5
On 6/4/08, Wendy Smoak [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 8:00 AM, Paul Spencer [EMAIL PROTECTED] wrote: -1 The copyright date in the notice file is 2007 instead of 2008 Aside from the copyright date, noted above, I only verified that notice.txt, manifest.mf and license.txt existed Probably needs to be fixed, though I could argue that If there haven't been any significant code changes this year, then 2007 may be correct. The copyright date starts when something is created, and I'm not sure packaging existing stuff==creation. I wouldn't stop the release because of this if it's the only problem. snip/ Yup, I wouldn't either. -Rahul
Re: [VOTE] Release Shale 1.0.5
On 6/5/08, Greg Reddin [EMAIL PROTECTED] wrote: On Thu, Jun 5, 2008 at 2:53 PM, Rahul Akolkar [EMAIL PROTECTED] wrote: 1) The *test* artifacts aren't meant to be distributed via releases, or used for anything beyond local testing, IIRC. (the usecases apps are meant to demo features). I would prefer we leave them out, to avoid many differences in this point release. You should be able to just blow those *test* directories / artifacts away in the m2 staging repo / dist area. Thanks, Rahul. Just to clarify, you're suggesting that we include the usecase apps in the release, but *not* include the *-test artifacts (except the ones that are core, like shale-test itself), correct? snip/ Yes, so the list of artifacts in v1.0.4 listed here (except obvious changes such as shale-tiles): http://markmail.org/message/kpy7tlfj6m2xq7e6 ... or some such. The important bit is to note the initial quality as beta. This is one of the things I did not do when posting the CfV for v1.0.4 (and we had to clarify that in a separate thread later). This way the release announcement can state the initial quality to be beta (and that it will potentially be revised later). I don't have a problem with that. IIRC, other projects (Struts, Tiles) don't specify the quality at all until after the release is posted. They just push a release and later declare it alpha, beta, or GA. I don't mind specifying initially that this will be beta if that makes people more comfortable voting. snap/ I have a slight preference for starting with a beta, but its your call :-) That won't affect my vote (I intend to check the artifacts by Saturday). -Rahul
Re: [VOTE] Release Shale Master POM Version 3
On 5/12/08, Greg Reddin [EMAIL PROTECTED] wrote: This is the formal vote for the new Shale master POM version 3. The former vote for the same version was cancelled due to problems in the POM. The POM was corrected and the release process was re-executed since the previous release had not been copied to the main repository. You can find the signed release candidate at [1]. Please vote +1 if you reviewed the new master pom and approve of it -1 if you found a flaw or potential problem with the new master pom snip/ +1 -Rahul Thanks, Greg [1] http://people.apache.org/builds/shale/m2-staging-repository/org/apache/shale/shale-master/3/
m2 gpg plugin (was Re: Update of ReleasePlan105 by GregReddin)
On 5/12/08, Apache Wiki [EMAIL PROTECTED] wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Shale Wiki for
change notification.
The following page has been changed by GregReddin:
http://wiki.apache.org/shale/ReleasePlan105
--
Maven did not do the GPG signing bit so I performed the following steps:
snip/
Its sometimes tedious to figure out why certain things are not
happening in the m2 build, but I think it'll be worthwhile spending
some time trying to fix this -- it will be a lot of work if you have
to manually sign the artifacts in the framework release(s).
-Rahul
{{{
- cd target/
+ cd target/checkout
gpg --armor --output shale-master-3.pom.asc --detach-sig pom.xml
scp shale-master-3.pom.asc
people.apache.org:/www/people.apache.org/builds/shale/m2-staging-repository/org/apache/shale/shale-master/3/.
}}}
Re: m2 gpg plugin (was Re: Update of ReleasePlan105 by GregReddin)
On 5/12/08, Greg Reddin [EMAIL PROTECTED] wrote: On Mon, May 12, 2008 at 11:18 AM, Rahul Akolkar [EMAIL PROTECTED] wrote: Its sometimes tedious to figure out why certain things are not happening in the m2 build, but I think it'll be worthwhile spending some time trying to fix this -- it will be a lot of work if you have to manually sign the artifacts in the framework release(s). True, I didn't think about that. I'll look into it. I saw something somewhere about the GPG plugin. I'm sure I can figure out how to add that goal to the release process. snip/ Ah, we don't have it in master :-) I think thats OK for now. Its already there in the release profile in the parent ... http://svn.apache.org/repos/asf/shale/framework/trunk/pom.xml ... so adding -Prelease should get that going for the framework releases. -Rahul Greg
Re: Master pom changes (was: Release Shale Master POM Version 3)
On 5/2/08, Greg Reddin [EMAIL PROTECTED] wrote: On Fri, May 2, 2008 at 10:42 AM, Paul Spencer [EMAIL PROTECTED] wrote: Greg, Thank you for the update. For clarification, what are you artifacts are you planning on releasing in the near future. We are going to try to do a 1.0.5 release of the entire framework. But there are a few changes that need to be made to the master pom first. So the plan is: 1) Bring the master pom up to date and release it. 2) Release 1.0.5 of all framework components. Then I will start looking at getting 1.1.0 up to snuff for a release. snip/ Sounds very good. I think the master pom is mostly ready for a vote (unless you're having issues with the build due to any particular now-locked-down plugin that you weren't having before). -Rahul Greg
Master pom changes (was: Release Shale Master POM Version 3)
On 4/18/08, Greg Reddin [EMAIL PROTECTED] wrote: I would like to cancel this vote and go ahead and implement the changes outlined by Rahul that will keep the site from redeploying when the master-pom is released. You can track progress in SHALE-487: https://issues.apache.org/struts/browse/SHALE-487 Any objections? snip/ None, thanks for doing this. If the master pom v3 hasn't been sync'ed to central, I don't mind doing a take 2 on it (otherwise we can move on to v4). I've locked down some other commonly used plugins. There are some TODOs, I'll comment on SHALE-487 where we're tracking this. -Rahul
Re: Master pom changes (was: Release Shale Master POM Version 3)
On 4/18/08, Greg Reddin [EMAIL PROTECTED] wrote: On Fri, Apr 18, 2008 at 3:19 PM, Rahul Akolkar [EMAIL PROTECTED] wrote: None, thanks for doing this. If the master pom v3 hasn't been sync'ed to central, I don't mind doing a take 2 on it (otherwise we can move on to v4). I was hoping to just redo it. It has not been sync'ed yet so I'll just svn rm the tag and the artifacts on the staging repo and to it over. snip/ Sure. -Rahul
Re: Shale validator wish list
Could you please open separate tickets for each item, along with any
patches you'd like to propose, in the Shale JIRA [1] (Validator
component) ?
Unless someone looks at this immediately, that will better ensure that
these stay on some roadmap.
-Rahul
[1] https://issues.apache.org/struts/browse/SHALE
On 4/16/08, Jeff Tsay [EMAIL PROTECTED] wrote:
Hi,
I've been trying to integrate the Shale validator stuff with xulfaces. I've
come across the following problems, some of which I have fixes for. Your
input would be appreciated, hope I can check some of the stuff in.
1) As I mentioned in the shale user mailing list, when the validator script
gets rendered, it outputs raw Javascript inside the script tags. The
Javascript includes characters like which need to be escaped or in a CDATA
section in XML. For XUL or XHTML, this is a problem. I guess that XHTML
parsers are more lenient about this so that's why the problem never showed
up? Anyway the fix, which was also suggested by Gary VanMatre, was to
enclose the script contents in an XML CDATA section. So in
src/main/java/org/apache/shale/validator/faces/ValidatorScript.java
I have:
private void writeScriptStart(ResponseWriter writer) throws IOException {
writer.startElement(script, this);
writer.writeAttribute(type, text/javascript, null);
writer.writeAttribute(language, Javascript1.1,
null);
writer.write(\n);
// jtsay added
// Enclose XML in CDATA so special characters can be used without
escaping.
if (!text/html.equals(writer.getContentType())) {
writer.write(![CDATA[\n);
}
}
and
private void writeScriptEnd(ResponseWriter writer) throws IOException {
// jtsay added
if (!text/html.equals(writer.getContentType())) {
writer.write(\n]]\n);
}
writer.write(\n);
writer.endElement(script);
}
This assumes if we are not rendering text/html, we must be rendering some
sort of XML. Sound reasonable?
2) It seems strange the way that configuration rules are loaded. If the
default configuration file is not found, the validator lifecycle listener
will add the default configuration file to the end of a url list. However,
since the list is processed in forward order, that means if you leave out
the default configuration file, any settings you have in your own file will
be overwritten by the default. That means you need to explicitly put the
default configuration file in your
org.apache.shale.validator.VALIDATOR_RULES list before your
own files. Since I think it makes more sense to have your specified
configuration files override the default settings, I propose the following
change in ValidatorLifeCycleListener:
private ValidatorResources
validatorResources(ServletContext context)
throws IOException, SAXException {
// Process the explicitly configured resources (if any)
// jtsay
// Since we want to add to the beginning later, use a linked list
// ArrayList urls = new ArrayList()
LinkedList urls = new LinkedList();
...
// Process the default configuration resources (if not already loaded)
if (!didDefault) {
try {
url =
context.getResource(Globals.DEFAULT_VALIDATOR_RULES);
} catch (MalformedURLException e) {
throw new
IllegalArgumentException(MalformedURLException:
+ The URL ' + Globals.DEFAULT_VALIDATOR_RULES
+ ' specified as a validator rules resource is
malformed.);
}
if (url == null) {
url =
ValidatorLifecycleListener.class.getResource(Globals.DEFAULT_VALIDATOR_RULES);
}
if (url == null) {
throw new
IllegalArgumentException(Globals.DEFAULT_VALIDATOR_RULES);
}
// jtsay
// Add to beginning of list so that explicit resources override
// default, not the other way around.
urls.addFirst(url);
}
3) Finally, I'd like to see the ability to override the validation error
handler. Currently, with the default validatorUtilities.js, whenever a
validation error occurs, an alert is displayed. To me that is a bit
unpolished; I'd rather see some message below the input field that has an
error. Although it's easy enough to replace validatorUtilities.js,
jcv_handleError() simply doesn't get enough information in its arguments to
do much with the DOM tree, unless the ID's of the elements to replace are
hardcoded. It would be good also to let the user supply his own error
handling script in the JSF tags, instead of messing with replacing
validatorUtilities (which would be apply across the entire web app anyway).
Any ideas on how to do this? Is anyone else interested in getting rid of
alert()?
Thanks,
Jeff
Re: Shale web page
On 4/15/08, Wendy Smoak [EMAIL PROTECTED] wrote: On Tue, Apr 15, 2008 at 11:19 AM, linux.eavilesa [EMAIL PROTECTED] wrote: Where is shale web page? Oops. Looks like someone deployed the site from the master POM. Can the guilty party please re-publish the website? :) snip/ Since Greg mentioned he'd be away, I've tried to rectify it. Waiting for the sync. -Rahul
Re: [VOTE] Release Shale Master POM Version 3
On Wed, Apr 9, 2008 at 11:59 AM, Greg Reddin [EMAIL PROTECTED] wrote: This is the formal vote for the new Shale master POM version 3. I would appreciate a thorough review of these artifacts since I am a release manager newbie :-) You can find the signed release candidate at [1]. Please vote +1 if you reviewed the new master pom and approve of it -1 if you found a flaw or potential problem with the new master pom snip/ +1 -Rahul Thanks, Greg [1] http://people.apache.org/builds/shale/m2-staging-repository/org/apache/shale/shale-master/3/
Re: 1.0.5 Release
On 3/24/08, Greg Reddin [EMAIL PROTECTED] wrote: Can someone doublecheck these two wiki pages and let me know if they are out of date? Will I be ok using these as a guide? I noticed there is no release plan page for 1.0.4. Was that intentional and/or should I create one for 1.0.5? snip/ If you think one is needed :-) I think the documentation below is fairly useful. The actual m2 commands, from memory, to create the necessary artifacts are along the following lines: * For framework: mvn -Prelease,apps,dist install site builds the necessary bits. * For apps, ISTR individually doing a mvn -Prelease assembly:assembly for each after the first bullet (perhaps this could be automated better) -Rahul http://wiki.apache.org/shale/ReleaseGuidelines http://wiki.apache.org/shale/ReleaseProcess Thanks, Greg
Re: 1.0.5 Release
On 3/24/08, Gary VanMatre [EMAIL PROTECTED] wrote: From: Greg Reddin [EMAIL PROTECTED] snip/ I'd like to volunteer to be the RM for a 1.0.5 release if everybody else is on board. I'm not a fast-mover and I'm not sure what my schedule will be but I would like to do it so I can understand the process. I'll start by reading up on the release process on the wiki and we can take it from there. Let me know if you have any objections to this direction. +1 I'll help out also. snap/ Whenever you're ready, if you work out a suitable date / weekend for a release, I'll try to be around as well on email / IM (standard disclaimers etc.) -Rahul
Re: [ANNOUNCE] New Shale PMC Chair
On 3/20/08, Antonio Petrelli [EMAIL PROTECTED] wrote: 2008/3/20, Greg Reddin [EMAIL PROTECTED]: In its meeting yesterday the Apache Board of Directors unanimously approved a resolution naming Gary VanMatre the new chair of the Apache Shale Project Management Committee. Please join us in congratulating Gary for this new role. Congrats Gary! I think that you are the right person that could restart development of Shale! snip/ +1 to that :-) -Rahul
Re: [clay] Clay: possible subproject of Tiles?
On 1/15/08, Ryan Wynn [EMAIL PROTECTED] wrote: On Jan 14, 2008 11:33 AM, Wendy Smoak [EMAIL PROTECTED] wrote: On Jan 14, 2008 8:59 AM, Antonio Petrelli [EMAIL PROTECTED] wrote: Hi all (and in particular Gary VanMatre). Now that Shale is being dismantled, I think that Clay could live as a subproject of Tiles, since its primary goal is to work with templates. I think that both projects could benefit from each other, though Clay is tightly connected to JSF. I actually don't think Shale is going anywhere... what seems more likely is that we'll retire bits of it (like the Tiles integration) in favor of other things that already exist, and _maybe_ split up the distribution so things can be released separately as people are interested in them. For what its worth, I am very interested in the future of clay as I have a lot of work invested in it. I am willing do whatever it takes to keep it around. snip/ Thanks. As you may have noticed in other threads, we are slowly (given some recent distractions) moving towards a new release. That being the case, it would be very helpful if you could try the latest code (specifically Clay, and whatever other modules interest you) in the active release branches [1],[2] and give us feedback. Such feedback is one of the important factors that will be used to determine the quality of the release, for example. Thanks again for your interest. -Rahul [1] http://svn.apache.org/repos/asf/shale/framework/trunk/ [2] http://svn.apache.org/repos/asf/shale/framework/branches/SHALE_1_0_X/
Re: [release] Last release of Shale?
On 12/6/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Matthias Wessendorf [EMAIL PROTECTED] Hi, as discussed already (here/[EMAIL PROTECTED]) there will be a move of Shale (or some parts of it), into MyFaces. But, before a thing like that will happen, we should release 1.0.5 1.1.0 I'd like to see another release. I know there are several outstanding bugs logged that need addressed. I hammered down a few several months ago but have not made the time to dig in again. I saw that Rahul did some work last week too. I think another release would be important on both branches. If we decide to merge with myfaces and don't take all of the existing modules, I'm not sure what that will do to people have investments in shale. For example, Ryan Wynn has shared that they have developed a very large portal (man years of development) using Clay. That's just one example and I'm sure there are others that have taken advantage of other parts of shale. For this reason, I'm rethinking the cafeteria proposal. I plan to be more active in the future. IMO, Shale is a lost leader now. Maybe Shale should consider pulling in more volunteers. That seems to be a secret to Struts success over the years. That leads to the next question, would they all be myfaces commiter anyway and would it just make sense to join communities. snip/ Glad to know that you're planning to be more active in the future, in the activity begets activity vein ( rather than launch into any new text, let me just point to Hen's notes [1] ). Also, I don't think we should be calling out releases as last releases (unless the PMC makes / has made that decision). I was occupied elsewhere in Apache land for a couple of weeks (and will be till the weekend), but I want to help with a release from one of the branches (say, 1_0_X). If this can happen at the year end, I will have more time. -Rahul [1] http://blog.generationjava.com/roller/bayard/entry/activity-begets-activity Gary WDYT? -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [release] Last release of Shale?
On 12/8/07, Wendy Smoak [EMAIL PROTECTED] wrote: On Dec 8, 2007 6:40 PM, Wendy Smoak [EMAIL PROTECTED] wrote: I'm looking at the 1.0.x branch, trying to get everything into a single distribution so that it's easy to release. Or not. I didn't realize how many example apps we have! I put them back in a profile so they're not part of the default build. Use -Dapps to activate the profile. I switched to the latest assembly plugin version (2.2-beta-1) and attached the framework distribution assembly so it should build during the normal lifecycle (i.e., when you type 'mvn site install' instead of having to type 'cd shale-dist; mvn assembly:assembly'.) The contents need to be verified, though. It might not be picking up the documentation. snip/ OK, I intend to take a look at the changes over the weekend. Looks like the two remaining issues are the snapshot version of the shale-master pom, and the Tiles dependency which is on an old snapshot. Shale Tiles does not compile against any release of Tiles 2. Is anyone planning to work on the Tiles integration? snap/ This seems to be on the critical path. Anyone? -Rahul -- Wendy
Re: Merging Shale into MyFaces
On 10/21/07, Craig McClanahan [EMAIL PROTECTED] wrote: big-snip/ * Dialog Manager * Dialog Manager (Basic Implementation) * Dialog Manager (SCXML Implementation) The Dialog Manager might be a next step for MyFaces Orchestra. Anyway, I hope that one of the original developers is still there to help out with things. +0 I like the idea of integrating this with Orchestra, although I'm not convinced that Spring should be a requirement to use this feature. If that's the case, you might as well use Spring Web Flow. The thing I like most about Shale Dialogs is that you really can abstract a significant amount of detail behind a common dialog interface, and then pick a back end implementation with varying sets of capabilities (and dependencies). Early on in Orchestra's life, I had suggested to Mario that it would be cool to have an adapter so you could Orchestra as your dialog implementation :-). snap/ While I'm on neither of the PMCs, I continue to be interested in Shale dialogs. And as long as I'm around, someone will try to answer user queries etc. -Rahul Longer term, this territory is going to get addressed by Web Beans (JSR-299), which is likely to include all the scope stuff (and more than Dialog has), coupled with annotation based dependency injection. But I've always felt that support for scopes other than request/session/application *really* belongs in the servlet spec so all Java web technologies can use it ... snip/
Re: [tld2claycfg] svn commit: r562848
On 8/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: hermod Date: Sun Aug 5 04:10:42 2007 New Revision: 562848 URL: http://svn.apache.org/viewvc?view=revrev=562848 Log: (empty) snip/ Please add a brief log message with a JIRA pointer, where possible. If you want, you can propedit the svn:log too, later. -Rahul
Re: svn commit: r558812 [1/4]
On 7/24/07, Gary VanMatre [EMAIL PROTECTED] wrote: snip/ Thanks for talking a look Rahul. We also have an issue with the parent pom from the plugin pom. I created the folder structure base on the pde maven plugin doc. The extra plugins folder hides the parent pom. Do you know if there is a way to override the location of the parent pom? I thought that I had seen that some place. snap/ Thanks for the detailed comments Gary! Sorry, I was mostly offline for a couple of days, and I see I'm too late to be of any help here since this seems to be taken care of (BTW, I didn't know the answer, but would have looked for it for a few minutes ;-) -Rahul
Re: svn commit: r558812 [1/4]
On 7/23/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: gvanmatre Date: Mon Jul 23 10:51:09 2007 New Revision: 558812 snip/ Added: shale/sandbox/shale-eclipse-plugins/ shale/sandbox/shale-eclipse-plugins/plugins/ shale/sandbox/shale-eclipse-plugins/plugins/shale_clay_plugin_for_eclipse/ shale/sandbox/shale-eclipse-plugins/plugins/shale_clay_plugin_for_eclipse/.classpath (with props) shale/sandbox/shale-eclipse-plugins/plugins/shale_clay_plugin_for_eclipse/.project (with props) shale/sandbox/shale-eclipse-plugins/plugins/shale_clay_plugin_for_eclipse/META-INF/ shale/sandbox/shale-eclipse-plugins/plugins/shale_clay_plugin_for_eclipse/META-INF/MANIFEST.MF (with props) shale/sandbox/shale-eclipse-plugins/plugins/shale_clay_plugin_for_eclipse/build.properties (with props) shale/sandbox/shale-eclipse-plugins/plugins/shale_clay_plugin_for_eclipse/icons/ shale/sandbox/shale-eclipse-plugins/plugins/shale_clay_plugin_for_eclipse/icons/Thumbs.db (with props) snap/ Stowaway? -Rahul
Re: Shale - Release
On 6/22/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Greg Reddin [EMAIL PROTECTED] On 6/22/07, Rahul Akolkar wrote: On 6/22/07, Matthias Wessendorf wrote: hi, are there any plans for 1.1.0 release ? As an aside, IMO its worthwhile to have a v1.0.5 as well so we can attempt to go GA in the 1.0.x line. Opinions? For the most part, the trunk and 1_0_x branch are the same. I can only think of one commit that was not made to the both. I'd like to see us move the trunk to JSF 1.2 and then we could mix in the annotations as part of the base libraries. snip/ shale-dialog has considerable deltas (the helper class, some new listener methods etc. -- many @since 1.1.0 tags if you dig into the code). This was under the understanding that no new features went into the 1.0.x line after v1.0.4. If we want to move trunk to JSF 1.2, that should either happen at v1.1.0 or should wait for the next line of development (v1.2.0) IMO. Depending on JSF versions and when currently unreleased new features frum trunk get released, here are the potential release scenarios: SCENARIO A: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.1, seeded from current trunk 1.2.x -- JSF 1.2 SCENARIO B: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.2, seeded from current trunk SCENARIO C: 1.0.x -- JSF 1.1, merge current deltas (mostly dialog new features) from trunk in 1.0.x line 1.1.x -- JSF 1.2, seeded from current trunk Preferences? -Rahul
Re: svn commit: r546943 - /shale/framework/branches/SHALE_1_0_X/shale-dialog-basic/src/main/java/org/apache/shale/dialog/basic/BasicDialogContext.java
On 6/13/07, Craig McClanahan [EMAIL PROTECTED] wrote:
Rahul,
Many many thanks for taking these on ... I work remotely so I can
generally skim email during long meetings (don't tell my boss :-), but
it's difficult to do substantitve stuff.
snip/
This one was hardly any work, you may be over-thanking me with those
many thanks :-)
-Rahul
Craig
On 6/13/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: rahul
Date: Wed Jun 13 09:08:46 2007
New Revision: 546943
URL: http://svn.apache.org/viewvc?view=revrev=546943
Log:
Subdialog not returning to calling dialog
SHALE-423
Have to execute action twice to return to calling dialog
SHALE-386
Porting r544613 from trunk.
Modified:
shale/framework/branches/SHALE_1_0_X/shale-dialog-basic/src/main/java/org/apache/shale/dialog/basic/BasicDialogContext.java
Modified:
shale/framework/branches/SHALE_1_0_X/shale-dialog-basic/src/main/java/org/apache/shale/dialog/basic/BasicDialogContext.java
URL:
http://svn.apache.org/viewvc/shale/framework/branches/SHALE_1_0_X/shale-dialog-basic/src/main/java/org/apache/shale/dialog/basic/BasicDialogContext.java?view=diffrev=546943r1=546942r2=546943
==
---
shale/framework/branches/SHALE_1_0_X/shale-dialog-basic/src/main/java/org/apache/shale/dialog/basic/BasicDialogContext.java
(original)
+++
shale/framework/branches/SHALE_1_0_X/shale-dialog-basic/src/main/java/org/apache/shale/dialog/basic/BasicDialogContext.java
Wed Jun 13 09:08:46 2007
@@ -411,6 +411,10 @@
position = peek();
if (position == null) {
stop(context);
+} else {
+transition(position, outcome);
+state = position.getState();
+continue;
}
viewId = ((EndState) state).getViewId();
redirect = ((EndState) state).isRedirect();
Re: svn commit: r518103 - /shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/config/beans/ComponentConfigBean.java
On 3/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: hermod
Date: Wed Mar 14 04:43:53 2007
New Revision: 518103
URL: http://svn.apache.org/viewvc?view=revrev=518103
Log:
Added fix for SHALE-424. ComponentConfigBean now checks it the config file is
empty before trying to create a URL from it
Modified:
shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/config/beans/ComponentConfigBean.java
Modified:
shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/config/beans/ComponentConfigBean.java
URL:
http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/config/beans/ComponentConfigBean.java?view=diffrev=518103r1=518102r2=518103
==
---
shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/config/beans/ComponentConfigBean.java
(original)
+++
shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/config/beans/ComponentConfigBean.java
Wed Mar 14 04:43:53 2007
@@ -37,6 +37,7 @@
import javax.servlet.ServletContext;
+import org.apache.commons.lang.StringUtils;
snip/
I think we should inline the StringUtils.isEmpty(String) call below.
This will avoid an explicit dependency on Commons Lang, which is
probably good unless we find ourselves inlining many bits, and over
and over.
Apparently, the only reason this builds is because Commons Lang is
pulled in transitively? (don't think we have an explicit dependency
for it).
-Rahul
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.shale.clay.config.ClayConfigParser;
@@ -270,12 +271,15 @@
urls.add(ui.nextElement());
}
} else {
- URL url = context.getResource(configFile.toString());
- if (url == null) {
- throw new
PageNotFoundException(messages.getMessage(file.notfound,
- new Object[] {configFile.toString()}),
configFile.toString());
- }
+ if(configFile!=null
!StringUtils.isEmpty(configFile.toString()))
+ {
+ URL url = context.getResource(configFile.toString());
+ if (url == null) {
+ throw new
PageNotFoundException(messages.getMessage(file.notfound,
+ new Object[] {configFile.toString()}),
configFile.toString());
+ }
urls.add(url);
+ }
}
} catch (IOException e) {
log.error(e);
Re: svn commit: r517688 - in /shale/framework/trunk: shale-application/ shale-apps/mailreader-jpa/ shale-apps/shale-blank/ shale-apps/shale-clay-usecases/ shale-apps/shale-mailreader-jpa/ shale-apps/s
On 3/13/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: hermod Date: Tue Mar 13 06:25:08 2007 New Revision: 517688 URL: http://svn.apache.org/viewvc?view=revrev=517688 Log: Added mising Tag handlers for validators and converters, and also updated the ignore list snip/ First of all, welcome -- glad to have you on-board and thanks for all your contributions to Shale (yes, I'm playing catchup with email :-). I have a few stylistic comments on this commit: * Please check your svn client for auto-props [1], the added files here don't seem to have props (particularly eol-style and keywords are what I care about). * AFAICT, at Shale we mark all commits against issues. This is particularly important with framework trunk (and other non-sandbox locations), IMO. * Usually better to stick to one purpose per commit (for example, here, adding the tag handlers and adding the svn:ignore bits would be well served in separate commits, again IMO). To humor the bullet above this one, then, we sometimes create catch-all issues (such as SHALE-310, which probably should have been closed at v1.0.4 release, but I digress). -Rahul [1] http://www.apache.org/dev/svn-eol-style.txt [2] http://issues.apache.org/struts/browse/SHALE-310 Added: shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/tag/DoubleConverterTag.java shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/tag/DoubleValidatorTag.java shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/tag/FloatConverterTag.java shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/tag/FloatValidatorTag.java shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/tag/LongConverterTag.java shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/tag/LongValidatorTag.java shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/tag/ShortConverterTag.java shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/tag/ShortValidatorTag.java Modified: shale/framework/trunk/shale-application/ (props changed) shale/framework/trunk/shale-apps/mailreader-jpa/ (props changed) shale/framework/trunk/shale-apps/shale-blank/ (props changed) shale/framework/trunk/shale-apps/shale-clay-usecases/ (props changed) shale/framework/trunk/shale-apps/shale-mailreader/ (props changed) shale/framework/trunk/shale-apps/shale-mailreader-jpa/ (props changed) shale/framework/trunk/shale-apps/shale-sql-browser/ (props changed) shale/framework/trunk/shale-apps/shale-test-tiger/ (props changed) shale/framework/trunk/shale-apps/shale-usecases/ (props changed) shale/framework/trunk/shale-clay/ (props changed) shale/framework/trunk/shale-core/ (props changed) shale/framework/trunk/shale-dialog/ (props changed) shale/framework/trunk/shale-dialog-basic/ (props changed) shale/framework/trunk/shale-dialog-scxml/ (props changed) shale/framework/trunk/shale-remoting/ (props changed) shale/framework/trunk/shale-spring/ (props changed) shale/framework/trunk/shale-test/ (props changed) shale/framework/trunk/shale-tiger/ (props changed) shale/framework/trunk/shale-tiles/ (props changed) shale/framework/trunk/shale-validator/ (props changed) shale/framework/trunk/shale-view/ (props changed) snap/
Re: Shale Dialog Manager
Please post usage questions to the user list, its this forum on nabble: http://www.nabble.com/Shale---User-f15689.html A quick answer below: On 3/9/07, Pich [EMAIL PROTECTED] wrote: Hi, I am wondering if there is anybody who has managed to start A DialogContext Via URL Parameters, as described here http://shale.apache.org/shale-dialog/index.html: In a use case like a pop-up window, the first request served by the application will be to a new window that is not currently associated with a current dialog. In order for such a window to immediately become associated with a DialogContext instance, the Dialog Manager also recognizes the following request parameters, if they are present, and if there is no active DialogContext already: * org.apache.shale.dialog.DIALOG_NAME - The logical name of the dialog to be created and started. * org.apache.shale.dialog.PARENT_ID - (Optional) the logical dialog identifier of a parent DialogContext instance that should become the parent of the newly created one. This allows, for example, a popup window to be associated with the data element for the DialogContext instance associated with the parent window. I cannot get this to work. snip/ See wizardpage2.jsp in any of the test apps for dialogs, the one for the basic impl (and 1.0.4 release) is here [1]. Search for zipCodePopup for an example. -Rahul (long URL below, might get fragmented) [1] http://svn.apache.org/repos/asf/shale/framework/tags/APACHE_SHALE_1_0_4/shale-apps/shale-test-dialog-basic/src/main/webapp/wizardpage2.jsp Regards Pich -- View this message in context: http://www.nabble.com/Shale-Dialog-Manager-tf3374345.html#a9390229 Sent from the Shale - Dev mailing list archive at Nabble.com.
Re: Promote the ShaleClayStarter archetype
On 2/27/07, Hermod Opstvedt [EMAIL PROTECTED] wrote: Hi Now that there are a couple of tutorials on the Wiki (and more to come) covering Shale and Clay and that is sparked off by the Maven Shale/Clay starter archetype, I'd like to call for a vote to promote it so that it gets into the distro. [X] +1 Yes (non-binding) [ ] 0 Don't care [ ] -1 No way snip/ +1 (non-binding) Thanks for your efforts. -Rahul P.S.-Better to prefix votes with [VOTE] Hermod
Re: [DialogContextManager] create(FC, String)
On 2/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, what do you guys think to change the method to return null, incase of there is no dialog with the desired name ? snip/ Change isn't source compatible, so hard to justify, I think. -Rahul P.S.- IMO, we should be porting things like typos you fixed today (thanks for that) to the 1_0_X branch as well. -M -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: See You In Amsterdam?
I won't be there, no talk for me. I'll be rooting from this side of the pond :-) Craig - Were you planning on talking about the dialog impls? It'd be great to see a larger picture being painted around the SCXML dialog impl beyond the runtime piece (entire dev cycle impact, same flow but multiple devices markups, potential standards angle etc.). If you want and/or prefer, I can post upto 2 slides, which ofcourse you're free to hack as you see fit. -Rahul On 2/2/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: how long are you staying in Europe, Sean ? wanna see Germany ? On 2/2/07, Sean Schofield [EMAIL PROTECTED] wrote: Craig, My wife and I are both going to be there. We're also planning on arriving early. Sean On 1/26/07, Craig McClanahan [EMAIL PROTECTED] wrote: My general session on Shale got accepted for ApacheCon Europe 2007 ... it's Friday May 4 at 10h30. Hope to see anyone else who is coming there! And I'm planning on coming in early enough for Queen's Day on Monday. Now I just need to go find an orange shirt ... Craig -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: See You In Amsterdam?
On 2/2/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 2/2/07, Rahul Akolkar [EMAIL PROTECTED] wrote: I won't be there, no talk for me. I'll be rooting from this side of the pond :-) Craig - Were you planning on talking about the dialog impls? It'd be great to see a larger picture being painted around the SCXML dialog impl beyond the runtime piece (entire dev cycle impact, same flow but multiple devices markups, potential standards angle etc.). If you want and/or prefer, I can post upto 2 slides, which ofcourse you're free to hack as you see fit. That would be very helpful! I could imagine spending a whole session talking about the dev cycle impact of building UIs around dialogs :-), but I should have time for a few slides on the topic. snip/ I made the whole session attempt ;-) *shrug* Thanks for being open to suggestions, I'll follow up in a week or two. -Rahul
Re: [ANNOUNCEMENT] Apache Shale 1.0.4 released
On 1/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: that contains the bug I fixed, are we providing a 104_1 ? snip/ Nope, those are the bits we voted on for 1.0.4. I think you are asking about SHALE-394, that will be available in subsequent releases (next in 1_0_X line is 1.0.5 ATM). We should discuss whether having bugfix releases for individual modules makes sense (so having a shale-view 1.0.4.1, rather than a framework 1.0.5 in this case). -Rahul .M
shale-view fix and process (was: ... 1.0.4 released)
On 1/23/07, Greg Reddin [EMAIL PROTECTED] wrote: On 1/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: I am pretty fine with a 1.0.5 instead of 1.0.4.1 ;) Me too :-) snip/ I definitely understand the desire for the fix to be available (and released). But I am even more interested in the process. Framework releases are coarser granularity and need more cycles, but provide a nice one-stop shop for all artifacts that work together. Modules are a finer granularity, and we can perhaps be more nimble releasing them, but we haven't released them separately. I was really looking for a discussion whether we want to go the latter route here, because that will entail a new set of procedural bits to be worked out (such as whether the shale-view-fix.jar is made available separately, what is its version number etc.). Going for a 1.0.5 without such a discussion is jumping the gun, IMO. Its possible we will have other comparable scenarios down the road. So lets pause and use this to create a process which will last Shale a lifetime, or half. -Rahul Greg
[v104] Initial quality (was: Mirror v104?)
On 1/12/07, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ OK, I'll post the proposed text for the announcement early next week and we can send it out then (by that time the site will have been updated, artifacts sufficiently mirrored etc.) snap/ OK, we're all set to announce now that Continuum has updated the site (thanks Wendy). The proposed text is at the bottom of the email [1], with the blurb about quality yet unfilled. Since the 1.0.4 release vote wasn't explicit about initial quality, we can either: (a) Mention the quality is undecided at this point (but will be voted on down the road) (b) Mention alpha quality (which may be upgraded later) (c) Hold a separate initial quality vote before announcing (IMO, alpha/beta probably appropriate candidates ATM) Preferences? -Rahul [1] Proposed text follows: The Apache Shale team is pleased to announce the release of Shale Framework version 1.0.4. The Apache Shale Framework is a set of loosely coupled services, fundamentally based on JavaServer Faces, which may be combined as needed to meet particular application requirements. Version 1.0.4 can be downloaded from the following page: http://www.apache.org/dyn/closer.cgi/shale/ ---QUALITY BLURB HERE, TBD--- This release includes the following significant new features and changes: * The Shale framework now contains six new modules, allowing application developers greater freedom over choosing the bits they need. The new modules are shale-application, shale-dialog, shale-dialog-basic, shale-dialog-scxml, shale-validator and shale-view. See the version 1.0.4 website for documentation on all modules: http://shale.apache.org/1.0.4/ * Several outstanding JIRA issues focusing on functional problems with the implementation of the Dialog feature have been addressed along with the refactoring in 1.0.4. * shale-clay has seen numerous improvements to the non-validating markup parser, template encoding, template namespace support, as well as JSF 1.2 basic support for Clay managed views and reduced inner dependencies for Servlet 2.3 compatibility. * It is now possible to build unit tests, using the shale-test module, that cater to JSF 1.2 APIs. Additionally, this version includes a substantial number of bugfixes and enhancements, full details can be found in the release notes: http://shale.apache.org/docs/release-notes-1.0.4.html Most of the framework APIs are reasonably stable, please see the following web page for more details: http://shale.apache.org/1.0.4/api-stability.html -Rahul Akolkar on behalf of the Apache Shale community ( http://shale.apache.org )
Re: svn commit: r496148 [1/2] - in /shale/sandbox/maven: ./ archetypes/ archetypes/shale-clay-starter-archetype/ archetypes/shale-clay-starter-archetype/src/ archetypes/shale-clay-starter-archetype/sr
On 1/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: gvanmatre Date: Sun Jan 14 13:01:07 2007 New Revision: 496148 URL: http://svn.apache.org/viewvc?view=revrev=496148 Log: Added the new shale-clay-starter-archetype contributed by Hermod Opstvedt to the sandbox for review (SHALE-391). This archetype will create a starter project that uses the RI components. I'd like to see us make archetypes the various component libraries also. Once we see how the Shale 1.0.4 release shakes out, we can move this and other archetypes out of the sandbox. snip/ Gary, Hermod -- Can you please take a look at the license headers for all files here? It seems some are missing the headers, while others are old school (so is the NOTICE file) -- basically, a RAT [1] run should come out clean. While this is the sandbox, these things will come up (and eat cycles) come graduation / release time, if not before. Thanks for the contribution Hermod. And thanks for your help, both. -Rahul [1] http://code.google.com/p/arat/
Re: ApacheCon (was: Release ...)
On 1/5/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 1/4/07, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ 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. snap/ I've proposed The quintessential controller, which will cover a case study involving Shale dialogs, if accepted. -Rahul
Re: Mirror v104? (was: RESULT ...)
On 1/11/07, Niall Pemberton [EMAIL PROTECTED] wrote: snip/ Struts posts a test build for a couple of weeks and then votes on the release and quality at the same time. If theres alot of change then the release might get voted initially as apha or beta. Once the release has been out there a while and there are no apparent problems we can vote again to upgrade the quality. It hasn't typically happened this way though because it has usually taken cutting several releaes before getting one without issues - so by the time we've voted a GA release theres often been at least a couple of betas before that. snap/ Here is the relevant recent example I mentioned in the last post ( [1] followed by [2] in a couple of weeks ) from tomcat's (recently improved) process. If and when I RM another Shale release, it will come with a quality marker to begin with (might as well be alpha, but mentioned explicitly). I prefer a release vote over a test build (that was not voted on). In any case, let me get back to completing the v1.0.4 release tasks. Many thanks for your input. -Rahul [1] http://marc.theaimsgroup.com/?l=tomcat-devm=116695917620851w=2 [2] http://marc.theaimsgroup.com/?l=tomcat-devm=116801203312451w=2 Niall
All clear 1_0_X branch (was: RESULT ...)
On 1/9/07, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ * Copy the m2 artifacts and the metadata files over to the m2-rsync repo * Copy the release artifacts (*.zip), readme to the /www/wao/dist space * Roll version numbers in 1_0_X branch * Sync up 1_0_X branch and trunk (except the 1.1 new features, ofcourse) snap/ Done. The 1_0_X branch is open for commits. As we've discussed: * bugfixes, minor improvements, build changes to both trunk and this branch * new features to trunk only One pending bit related to the v1.0.4 release is to update the Shale home page releases section and add a link to 1.0.4 site [1]. Giving some time for the rsyncs etc., I'll make that change once I get back from the weekend ski trip (need to travel quite a bit for snow ATM!). -Rahul [1] http://shale.apache.org/1.0.4/ Thanks for your time, all. -Rahul
Re: Mirror v104? (was: RESULT ...)
This ones thoroughly OT, sorry list. On 1/11/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 1/11/07, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ Here is the relevant recent example I mentioned in the last post ( [1] The quality grade in that initial post is in the title [VOTE] Release build 6.0.7 as alpha - so they are doing the same as Struts - voting on an initial release as alpha quality. I assume the second post is then a vote to either keep it as alpha or upgrade it to beta. snap/ Indeed, got that. And the two reasons you state [A] where voting twice is not necessary also make good sense. But, is the above the same as the Struts process ATM? I seem to remember a 2.0.1 quality vote and now talk of 2.0.3, but no vote at all for 2.0.2 (I may have just missed it, if so, sorry). -Rahul [A] http://www.nabble.com/Re%3A-Why-vote-twice-for-a-release-quality--p4246751.html Niall followed by [2] in a couple of weeks ) from tomcat's (recently improved) process. If and when I RM another Shale release, it will come with a quality marker to begin with (might as well be alpha, but mentioned explicitly). I prefer a release vote over a test build (that was not voted on). In any case, let me get back to completing the v1.0.4 release tasks. Many thanks for your input. -Rahul [1] http://marc.theaimsgroup.com/?l=tomcat-devm=116695917620851w=2 [2] http://marc.theaimsgroup.com/?l=tomcat-devm=116801203312451w=2
Re: Mirror v104? (was: RESULT ...)
On 1/9/07, Niall Pemberton [EMAIL PROTECTED] wrote: On 1/9/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 1/9/07, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ Pending 24 hours for reporting any errors in counting etc., I plan to complete the release tasks: * Copy the m2 artifacts and the metadata files over to the m2-rsync repo * Copy the release artifacts (*.zip), readme to the /www/wao/dist space snap/ Should have stressed on the above bullet. v103 posted release artifacts in the people.apache.org/dist space [1], whereas doing the above for v104 will actually cause the release to be mirrored. So, true or false: v104 should be mirrored. Since this is an official Apache release authorised by the Shale PMC then it can (and should IMO) be distributed in the official (mirrored) repositories. snip/ Yup, my understanding also. What led me to pause (and question) is the fact that the dist space [1] is empty ATM. I plan on creating two directories in that space: * framework/ * apps/ filled with the corresponding 1.0.4 artifacts and with current symlinks at the top level (dist/shale/) [1] http://www.apache.org/dist/shale/ (more below ...) The thing I think is confusing is that you didn't vote on a quality - as I understand you're thinking of having different quality grades for different components because of tiles(?) Anyway whatever the process you're using for quality IMO it would be better to determine this before announcing the release - as I'm sure people will either assume its GA quality or wonder what its designation is (alpha, beta, GA). snap/ Correct, the announcement is not even on my todo list yet ;-) My understanding is (from observing tomcat, think struts does similarly) that the quality vote usually follows in a couple of weeks after the release vote, followed by the announcement. Wendy was, I think (IIRC and all other disclaimers included), proposing that release vote come with a proposed default quality but I didn't hear anything after that (and was not the case with v1.0.4 either). -Rahul Niall
Re: svn commit: r494333 - in /shale/framework/trunk: shale-apps/shale-test-dialog-basic/src/main/webapp/ shale-apps/shale-test-dialog-scxml/src/main/webapp/ shale-dialog/src/main/java/org/apache/shale
On 1/9/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: craigmcc Date: Mon Jan 8 23:13:55 2007 New Revision: 494333 URL: http://svn.apache.org/viewvc?view=revrev=494333 Log: [SHALE-389] Implement a dialogScope pseudo-variable that is equivalent (in the current implementations) to dialog.data but could be specialized later. This slightly simplifies binding expressions in JSF views, but (more importantly) hides an implementation detail and offers the opportunity for more advanced functionality to be applied later, without having to modify existing JSF views (or use of binding expressions programmatically in backing beans). snip/ Modified: shale/framework/trunk/shale-dialog/src/main/resources/META-INF/faces-config.xml URL: http://svn.apache.org/viewvc/shale/framework/trunk/shale-dialog/src/main/resources/META-INF/faces-config.xml?view=diffrev=494333r1=494332r2=494333 == --- shale/framework/trunk/shale-dialog/src/main/resources/META-INF/faces-config.xml (original) +++ shale/framework/trunk/shale-dialog/src/main/resources/META-INF/faces-config.xml Mon Jan 8 23:13:55 2007 @@ -30,6 +30,7 @@ application navigation-handlerorg.apache.shale.dialog.faces.DialogNavigationHandler/navigation-handler + variable-resolverorg.apache.shale.dialog.faces.DialogVariableResolver/variable-resolver /application snap/ Please svn add+ci DialogVariableResolver. -Rahul
Re: [FWD: [v1.0.4] shale-tiles and release notes (was Re: svn commit: r490857 ...)]
On 1/5/07, Gregg Leichtman [EMAIL PROTECTED] wrote: Additionally, note that the framework distribution (nightlies or release) contains all dependency jars in the lib folder Ok, that is _very_ useful (thanks, I had not noticed this and had been going out on my own for the past few months to try and match components up with Shale nightlies with various levels of success); however, when I go to the Tiles core download site at: http://people.apache.org/builds/struts/nightlies/tiles/ I find: snip-list/ None of the versioning above matches the versioning of the file tiles-core-2.0-r468346-SNAPSHOT.jar provided in the framework, so how can I correlate the two? Continue reading. snap/ Its in the snapshot repository (long, possible fragmented URL) that is used by the build: http://people.apache.org/repo/m2-snapshot-repository/org/apache/struts/tiles/tiles-core/ Its also available on the website, the dependency page for shale-tiles is here: http://shale.apache.org/shale-tiles/dependencies.html This is good also; however, I can't find any place on this page where it states which version of Shale these dependencies go to. I assume that since 1.0.3 is the currently released version of Shale, these dependencies apply to it, but that doesn't seem to be stated. If this is true, then I assume that tiles-core-2.0-r468346-SNAPSHOT.jar applies to Shale 1.0.3. Correct? If this is correct, maybe the dependencies page can have a blurb in it to state which version of Shale the dependencies apply to. Since the page is generated by Maven, maybe Maven makes this too hard to do. snip/ That version applies to (a probably soon to be out) Shale 1.0.4 or a recent nightly. For Shale 1.0.3, it wasn't pinned down to a specific svn revision (and your best bet is, again, to pick up the jar that would have come in the lib/ directory of the 1.0.3 framework distro). Your point about trying to correlate this information (especially for someone not used to Maven and its sites) is however well taken. (similarly for other modules -- for each module, the 'Project Documentation' section in the left side navbar has this, and other, information). I don't see anything relevant under the Project Documentation section. I do see sub-projects under Sub-Project Documentation, but these don't appear to supply versioning information. For example, the link http://shale.apache.org/shale-tiles/index.html for tiles. snip/ For example, the project summary has the version number of the artifact you're looking for: http://shale.apache.org/shale-tiles/project-summary.html If there are further questions, we should probably move this to the user list. -Rahul -= Gregg =-
Mirror v104? (was: RESULT ...)
On 1/9/07, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ Pending 24 hours for reporting any errors in counting etc., I plan to complete the release tasks: * Copy the m2 artifacts and the metadata files over to the m2-rsync repo * Copy the release artifacts (*.zip), readme to the /www/wao/dist space snap/ Should have stressed on the above bullet. v103 posted release artifacts in the people.apache.org/dist space [1], whereas doing the above for v104 will actually cause the release to be mirrored. So, true or false: v104 should be mirrored. -Rahul [1] http://people.apache.org/dist/shale/v1.0.3/ * Roll version numbers in 1_0_X branch * Sync up 1_0_X branch and trunk (except the 1.1 new features, ofcourse) Thanks for your time, all. -Rahul
Online docs and releases
We should probably look into posting 1.0.4 docs online (since the trunk is going to have an ever-increasing delta). I was thinking of packaging up the 1.0.4 site and exploding a scp'ed tarball into /www/sao/1.0.4 Objections? Better way to post the 1.0.4 site? -Rahul
Continuum and profiles (was: Release ...)
On 1/5/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 1/4/07, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ 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 :-). snap/ ;-) On a similar note, is continuum currently using the apps profile? (Wendy?) For example, the navbar and no logo on shale-sql-browser [1] are signs its dated. -Rahul [1] http://shale.apache.org/shale-apps/shale-sql-browser/index.html Craig
[VOTE] Shale version 1.0.4 Release
Once more, with a slightly different subject to keep archives and email clients happy. This is a vote to release Apache Shale version 1.0.4. There are no functional changes since the last vote (delta addresses Niall's comments). This vote is scheduled to close in 72 hours (Monday 8th late afternoon EST). (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: [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: [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: [v104] Ready
On 12/31/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 12/31/06, Rahul Akolkar [EMAIL PROTECTED] wrote: No pending issues against 1.0.4 snap in JIRA ATM (the couple of open ones are sufficiently addressed IMO), so pending ~24 hours for any feedback on the dry run (let me know if you need more time), I will move towards a final set of proposed artifacts (and a vote). -Rahul Picking my way through the release notes (nice job on the updates :-), I notice we still have the following statement regarding the expected final vote: - snip - This is the fourth milestone release of Shale, released to encourage experimentation and gather feedback on usage issues and requested features. A final vote on quality has yet to take place for this release, but it will likely be voted to be of beta quality due to the following issues: - Reliance on a snapshot of the unreleased Standalone Tiles package. However, many of the APIs in Shale are reasonably stable -- for details, see Shale API Target Audiences and Stability Ratingshttp://shale.apache.org/api-stability.html . - snip - We had talked earlier about the idea of doing quality rankings on the individual packages separately, so that we'd have a chance to grant a GA quality vote on some remaining portion other than shale-tiles. If we still feel this way, I'd suggest modifying this text to something like this: This is the fourth milestone release of Shale, released to encourage experimentation and gather feedback on usage issues and requested features. A full vote on quality has yet to take place for this release, but will take place later. We plan to vote on the quality of each module separately (where necessary). For example, the shale-tiles module is likely to receive a grade no higher than Beta because it relies on a snapshot of the as-yet unreleased Standalone Tiles package. As a plan B, we could pull shale-tiles from this release entirely, and release it separately (with its own release grade vote), as I'm pretty confident that this would be the only exception. I'd be OK with this but would still prefer that everything was packaged together and we did the vote rankings specficially, with wording something like the above. Thoughts? snip/ Agreed (I prefer Plan A), thanks for the feedback. The previous blurb existed in the 104 release notes since this thread didn't get much feedback as to what that blurb should be: http://tinyurl.com/y6dnbe I have now updated the notes based on this feedback. -Rahul Craig
Code freeze 1.0.x branch
The SHALE_1_0_X branch [1] has been created. Over the next day, it will be used to prepare the proposed v1.0.4 artifacts and svn tag. My preference would be to have no commits to the branch when releases are being prepared and voted on (relevant commits to trunk that need to be backported can wait a day or two, unless its a showstopper for the release). I will ping this thread when this is done for v1.0.4, and the branch is open for general commits. -Rahul [1] http://svn.apache.org/repos/asf/shale/framework/branches/SHALE_1_0_X/
Re: Code freeze 1.0.x branch
On 1/1/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 1/1/07, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ More generally, I propose we have the following procedure for future releases: (1) At the appropriate time, the RM declares a code freeze on the relevant branch (2) Development continues in all other branches, and developers keep notes of any changes that need to be ported to the frozen branch (3) When freeze is over, developers commit pending changes Showstoppers that require a fix to the frozen branch restart the process at (1). Sounds like a good general policy, although I suspect there generally will *not* be pending changes that we did not already discuss and decide on -- it will probably amount to a few patches that were deemed not critical to getting a maintenance release out the door. But time will tell :-). snap/ Agreed :-) In the mean time, I'll go ahead and update the trunk version numbers to 1.1.0-SNAPSHOT, per our previous discussions. I've also added a JIRA version for this, so we can start tagging issues for new development as they get dealt with there. snip/ Sounds good, thanks. -Rahul Craig
Re: svn commit: r491671 - in /shale/framework/trunk: ./ shale-application/ shale-apps/ shale-apps/mailreader-jpa/ shale-apps/shale-blank/ shale-apps/shale-clay-usecases/ shale-apps/shale-mailreader-jp
On 1/1/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: craigmcc Date: Mon Jan 1 14:58:04 2007 New Revision: 491671 URL: http://svn.apache.org/viewvc?view=revrev=491671 Log: Advance trunk version numbers from 1.0.4-SNAPSHOT to 1.1.0-SNAPSHOT now that 1.0 has been branched. SHALE-383 Modified: shale/framework/trunk/pom.xml snip/ The shale-master version in shale-parent should be 3-SNAPSHOT, though I'm not sure if continuum will install it locally by itself. -Rahul
[v104] Ready
No pending issues against 1.0.4 snap in JIRA ATM (the couple of open ones are sufficiently addressed IMO), so pending ~24 hours for any feedback on the dry run (let me know if you need more time), I will move towards a final set of proposed artifacts (and a vote). -Rahul
Re: [v104] Feedback on dry run
On 12/29/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 12/29/06, Wendy Smoak [EMAIL PROTECTED] wrote: snip/ The first thing I notice is that there are no version numbers in the filenames. I expected to see shale-framework-1.0.4-SNAPSHOT.zip, etc. I manually removed the version number from that one and mailreader-jpa (apparently the apps' assemblies don't get the version numbers in them, can you please try the assembly in shale-blank, for example). snap/ On the subject of artifact names and minimal manual intervention, do we care about the '-dist' suffix to the assemblies? If not, having a blank id in the assembly descriptors will help (with the downside that it will no longer be possible to point to the descriptor via its id, particularly relevant if we ever have more than one). -Rahul
Re: [v1.0.4] Release notes (clay improvements etc.)
On 12/29/06, Gary VanMatre [EMAIL PROTECTED] wrote: From: Rahul Akolkar [EMAIL PROTECTED] I'm done with changes to the release notes for now (commits@ list seems to have a lag right now). Please jump in and improve them. I have left one FIXME for any notable Clay changes that we may want to list as was done for 1.0.3 (Gary?), but anything else worth mentioning should go in section 3 and 4 as well. TIA. I'm snowed in for the rest of the year so I'll have some time to work on this today. snip/ Thanks. However, I have a FedEx box ready to send my laptop into the shop. When the sucker gets overheated it just powers off. I might have to sit in the 6 foot snow pile outside my house to keep her cool :-). snap/ Yeah, those things can do more damage than shutting off these days ... no snow yet in the big apple, it was strange to have multiple rounds of golf a week till late December :-) -Rahul -Rahul Gary
Re: [v1.0.4] Release notes (clay improvements etc.)
On 12/29/06, Gary VanMatre [EMAIL PROTECTED] wrote: From: Rahul Akolkar [EMAIL PROTECTED] On 12/29/06, Gary VanMatre wrote: From: Rahul Akolkar I'm done with changes to the release notes for now (commits@ list seems to have a lag right now). Please jump in and improve them. I have left one FIXME for any notable Clay changes that we may want to list as was done for 1.0.3 (Gary?), but anything else worth mentioning should go in section 3 and 4 as well. TIA. I'd like to mentions SHALE-324 in there but it doesn't pertain to the release artifacts. We haven't talked about how or if we are going to release the tools. I should have spoken up earlier. What do you think? snip/ I think we should talk about tools so its clear what the roadmap is. They currently sit outside framework -- is that a separate unit of release, or to be included in framework releases etc. Also, I think its too last minute for including anything new at all in framework v1.0.4. We're ready, pending release notes tweaks and the like. However, thats just one opinion, if enough of us think this should be part of v1.0.4, we should get things in place soon (in a day or two would be my preference). Yeah, those things can do more damage than shutting off these days ... That's what I'm afraid of. I can cause a power off by just running a bios check. I sure hope they take good care of her. snap/ Good luck with that Gary, hope she comes out well. -Rahul
[v104] Feedback on dry run
I did a dry run of the release artifacts (dry since its based on trunk from earlier today, all versions are snaps): http://people.apache.org/~rahul/shale/v104snap/ (m2 artifacts in repos) If you get a chance, try inspecting a few artifacts, early feedback would be great. Planning on using the same procedure for producing artifacts for the release vote, in a couple of days. -Rahul
Re: [v1.0.4] artifacts list, release notes, API stability
On 12/28/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 12/28/06, Rahul Akolkar [EMAIL PROTECTED] wrote:
snip/
Apps:
shale-blank-1.0.4.zip
shale-clay-usecases-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
These are the assembly outputs that include the sources and dependent
libraries, right?
snap/
Yes, sources, any site docs and the war (which includes all dependency
libraries in WEB-INF/lib). Basically whatever the assembly descriptor
does.
I just looked at shale-blank and it seems our wars are including
{avalon, log4j, logkit, servlet-2.4} in WEB-INF/lib. Looks like we are
missing the exclusions in shale-apps-parent, will try to track this
down in a bit.
Separately, I see (and agree with you) that you're proposing to include only
zips, not .tar.gzs. If that's the future, we might as well rip creating
tar.gz files out of the assemblies and save a few more seconds when we run
them.
snip/
I was staring at this when I made that list:
http://people.apache.org/dist/shale/v1.0.3/
Looks like we did zip only for 1.0.3. I see the assembly descriptors
produce both. I don't mind having both, its not much additional work
at all. WDYT?
(ii) m2 repo artifacts:
POMs:
shale-parent-1.0.4.pom
shale-apps-parent-1.0.4.pom
Don't we need the POMs for all of the framework jars below as well?
snap/
Ofcourse, that didn't come out correctly :-) I was focusing on POM
packaging but yes, the POMs will be deployed as well (mvn deploy
will do that).
-Rahul
Craig
[v1.0.4] Release notes (clay improvements etc.)
I'm done with changes to the release notes for now (commits@ list seems to have a lag right now). Please jump in and improve them. I have left one FIXME for any notable Clay changes that we may want to list as was done for 1.0.3 (Gary?), but anything else worth mentioning should go in section 3 and 4 as well. TIA. -Rahul
Re: [RESULT][VOTE] Release Shale Master POM version 2
On 12/27/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 12/27/06, Craig McClanahan [EMAIL PROTECTED] wrote: The md5 and sha1 checksums are fine. When I try to verify the signature, though: gpg --verify shale-master-2.pom.asc shale-master-2.pom I get the Can't check signature: public key not found error. I see that your key is available (at least) on the MIT keyserver ... what's the magic incantation for using such a key (without adding it to my web of trust yet ... we should probably start doing key exchanges at events like ApacheCons)? I think it's: gpg --import file Rahul, please add your key to http://www.apache.org/dist/shale/KEYS (which should be in svn somewhere, but I don't see it.) snip/ Sure, will do that before sending the master pom over to the sync repo. Thanks for the reminder (don't think we have it in SVN, will add to your dist/ pointer above on pao). -Rahul -- Wendy
Re: [RESULT][VOTE] Release Shale Master POM version 2
On 12/27/06, Craig McClanahan [EMAIL PROTECTED] wrote: snip/ Yep ... that worked. I got the good signature and untrusted messages. snap/ OK, so we're good to go on the master pom. Thanks. I should have mentioned also what Wendy said ... we should follow the best practice of maintaining our KEYS file in SVN ... if I remember right, it's only on the website at the moment. snip/ Indeed. Where? framework/trunk? -Rahul Craig
Re: svn commit: r490580 - /shale/framework/trunk/shale-validator/src/main/resources/org/apache/shale/validator/messages_nl.properties
On 12/27/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 12/27/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 12/27/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: craigmcc Date: Wed Dec 27 14:33:45 2006 New Revision: 490580 URL: http://svn.apache.org/viewvc?view=revrev=490580 Log: Add Dutch translations for the validator messages. Thanks to Joost Schouten for the patch (SHALE-372). Don't forget to update the list of contributors in the master pom. I've made a note to do that as soon as Rahul is through with this release and updates the checked-in version number to be a snapshot again. snip/ Done, 3-SNAPSHOT now. -Rahul Craig -- Wendy
POMs cruft
Few thoughts: 1) Why is the dependencies section in the parent pom commented out? Tempted to remove it. 2) We probably want to move designtime into a profile (can wait post 1.0.4). 3) There is some other cruft in the parent and remoting poms that I intend to remove. Objections to 1 or 3? -Rahul
[v1.0.4] All aboard
Branching tomorrow. Please speak up now if you want more time. -Rahul
Re: POMs cruft
On 12/27/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 12/27/06, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ 2) We probably want to move designtime into a profile (can wait post 1.0.4). It should probably go back into the sandbox at the moment ... it's on my list to work on in 2007, but that will take a bit of time. snap/ In that case, I can move it to sandbox tomorrow before branching. Is that OK? -Rahul Craig
Permissions for site KEYS file
The permissions for the KEYS file [1] seem botched after being restored from backup. Guess we'll need to ping #asfinfra ? (I'm never on it though, anyone? TIA). -Rahul [1] http://www.apache.org/dist/shale/KEYS
Re: Permissions for site KEYS file
For thread closure, this has been taken care of (thanks Craig). -Rahul On 12/28/06, Rahul Akolkar [EMAIL PROTECTED] wrote: The permissions for the KEYS file [1] seem botched after being restored from backup. Guess we'll need to ping #asfinfra ? (I'm never on it though, anyone? TIA). -Rahul [1] http://www.apache.org/dist/shale/KEYS
[RESULT][VOTE] Release Shale Master POM version 2
Shale Master POM version 2 release vote passes with 4 binding +1s from: Craig McClanahan Greg Reddin Wendy Smoak Gary VanMatre No other binding votes. Following a 24 hour buffer for reporting any counting errors, artifact will be in the m2 rsync repo. Thanks to those who took time to review and participate. -Rahul On 12/22/06, Rahul Akolkar [EMAIL PROTECTED] wrote: In preparation for the framework release version 1.0.4, the Shale Master POM has been updated: http://tinyurl.com/ymy9ap (diff with v1) tagged (long URLs below, may get fragmented): http://svn.apache.org/repos/asf/shale/maven/tags/SHALE_MASTER_2/ and deployed to the staging repository: http://people.apache.org/builds/shale/m2-staging-repository/ This is a vote to release the tagged (and deployed) artifact above as version 2. --8--- [ ] +1 [ ] 0 [ ] -1, because ... --- Given the holiday weekend, vote will remain open for 96 hours (closing around noon Eastern US time, December 26th). -Rahul
Re: [RESULT][VOTE] Release Shale Master POM version 2
On 12/26/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 12/26/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Following a 24 hour buffer for reporting any counting errors, artifact will be in the m2 rsync repo. Thanks to those who took time to review and participate. While I'm thinking of it... I checked the pom, but not the signature and checksums. (And people.a.o is down atm, so I can't look now.) snip/ OK, I'll wait till pao is good again (and this is sorted out). I don't remember signing the pom with my key (will do it once I get a chance). I used 'mvn deploy' so m2 summed it for me. Let me know if the missing sig is reason for a new vote. -Rahul -- Wendy
Re: [RESULT][VOTE] Release Shale Master POM version 2
On 12/26/06, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ Back on track, will sign the pom, and will ask this list to verify it before copying over. (BTW, is there a way to get m2 to sign?) snap/ Done, I've added my signature to the master pom v2 in the staging repo. My key is here [1] amongst other places (I intend to add a generic UID before 1.0.4). Please verify the sig (and m2 sums). TIA. -Rahul [1] http://people.apache.org/~rahul/rahul.asc -Rahul
Re: [VOTE] Release Shale Master POM version 2
On 12/22/06, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ This is a vote to release the tagged (and deployed) artifact above as version 2. --8--- [X] +1 [ ] 0 [ ] -1, because ... --- snap/ This vote is non-binding. -Rahul
Re: svn commit: r489275 - in /shale/framework/trunk/shale-dialog-basic/src: main/java/org/apache/shale/dialog/basic/BasicDialogContext.java site/xdoc/index.xml
On 12/21/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 12/20/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: craigmcc Date: Wed Dec 20 23:37:50 2006 New Revision: 489275 URL: http://svn.apache.org/viewvc?view=revrev=489275 Log: Document the support for dealing with SHALE-61 issues (back and forward buttons) that will be present in the 1.0.4 release. With this commit, I'm satisfied with the shale-dialog-basic support for back and forward buttons, as documented in issue SHALE-61, for the 1.0.4release. As soon as Rahul commits his changes for shale-dialog-scxml (pending the propogation of the Commons SCXML 0.6 release), we can call this issue Fixed and move forwards with the release. snip/ OK, the maven repositories have v0.6 now (though we have missing checksums ATM). I've committed the shale-dialog-scxml bits for SHALE-61. FWIW, a quick visual inspection seems to suggest that there is a difference currently between the two impls in that the basic one doesn't seem to fire the DCL callbacks as we discussed (I've kept it at onEntry/Exit for now). So I'm leaving the issue open, need to leave right now (travel weekend). -Rahul Craig
Re: Release branch (was Re: Release Status)
On 12/20/06, Greg Reddin [EMAIL PROTECTED] wrote: Just a question: are you keeping good notes as to what you're doing? I'd like for the details of the process to end up on a wiki page if they are not already there. After reading these messages I have no clue what you are doing :-) snip/ I'm just going through the release guidelines [1] and process [2], and clarifying those things that I feel the need to double check with everyone. I'll try to add to the wiki docs if something needs adding/changing, so far so good. For example, the branching discussed in this thread has to do with the first bullet in the Final Snapshot Review section of the guidelines [1] relating to continuum (and we were planning on having two lines anyway -- 1.0.x and 1.1.x). In summary, this is nothing revolutionary here. Having said that, at any point, please feel free to stop me and ask what I am doing (or why I am doing it, or where it is documented, or why it is not documented etc. :-). -Rahul [1] http://wiki.apache.org/shale/ReleaseGuidelines [2] http://wiki.apache.org/shale/ReleaseProcess Greg snap/
Re: Release branch (was Re: Release Status)
On 12/19/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 12/19/06, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ OK, if everyone's fine with that, I will create the 1.0 branch (called SHALE_1_0_x unless there are better suggestions) when we get closer to the release (after all 1.0.4-SNAP issues are resolved and the master pom is released etc.) I would have a mild preference for naming the branch SHALE_1_0 but I'm not going to choke if we go with what you proposed either. I'm also presuming we'll create a tag (SHALE_1_0_4) at the appropriate time. snap/ Indeed, the framework/ will be tagged when the time is right. As regards to the name of the branch, I prefer 1_0_x over 1_0 since the former looks like a line of development to me (the latter more like a branch for a single release). However, this isn't anything I want to spend time over. You pick. -Rahul
Re: Releasing shale master pom
On 12/19/06, Craig McClanahan [EMAIL PROTECTED] wrote: snip/ * I like the habit I've seen Rahul and others do in Commons, of adding contributor entries for those who have posted patches. A quick scan of our issues might be useful. snap/ This becomes hard after the fact. If we decide to do this (I think we should), we must continually update the contributors section in the future. I came up with a starter set after a few minutes looking around (at the end of the email). If we're doing this for master pom v2, we need everyone to jump in now (i.e. within a day or two) and complete the starter set by reviewing their own commits and making necessary additions. Note that this leaves out any Struts folks (except some that are pulled in by some issue), so someone should review that as well. Then there is the question of ordering (alphabetical, chronology of contribution etc. can be criteria for sorting). I like chronology (so the order would be the same as below -- then new contributors just get added to the end). The bits in bracket are for reference only and obviously won't be in the pom. So, again, please complete this. -Rahul Duncan Mills (SHALE-2) Ronald Holshausen (SHALE-3) Manfred Klug (SHALE-4) David DeWolf (SHALE-27) Keijo Numes (SHALE-43) Shane Bryzak (SHALE-45) Ted Husted (SHALE-76) Dennis Bryne (SHALE-78) Richard Wallace (SHALE-84) Bill Young (SHALE-106) Alexandre Poitras (SHALE-114) Hubert Rabago (SHALE-131) David Thielen (SHALE-148) Ed Burns (SHALE-178) Ingo Dueppe (SHALE-190) Jack Cheng (SHALE-203) Niall Pemberton (SHALE-207, wiki reorg) Marcello Teodori (SHALE-232) Reind (SHALE-247) Mike Kienenberger (SHALE-251) Andrew Gilette (SHALE-255) Ryan Lubke (SHALE-270) Shinsuke Sugaya (SHALE-282) Mario Ivankovits (SHALE-296) Hermod Opstvedt (SHALE-324) Mike Meessen (SHALE-327) Luis Parravicini (SHALE-370) Ryan Wynn (http://wiki.apache.org/shale/ReusableClayJars) Rene Zanner (wiki documentation) Adrian Mitev (wiki documentation) Simon Kitching (wiki documentation) Craig
Releasing shale master pom
Figure we should get that going while we wrap up on 1.0.4 code, otherwise a 72 hour buffer (at the least). I'm not aware of any pending changes ATM, but if you have any, please go ahead. Some procedural bits, yell if incorrect: * I can't find the v1 tag (probably somewhere is Struts land, not sure) but the v2 tag will be at maven/tags * 'mvn deploy' master pom to staging repo (which should be the repo of choice once the snapshot marker gets removed) and when vote passes do a *nix 'cp' on people of the 2/ directory and maven-metadata.* from the staging repo to the m2-ibiblio-repo. Wanted to confirm that the metadata copy, in particular, is OK. -Rahul
Release branch (was Re: Release Status)
On 12/17/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 12/16/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Sounds like reasonable things to do :-) We even have a staging repo defined in the master pom (thanks Wendy) which we should use for this. By default if the version doesn't end in -SNAPSHOT, the artifacts will end up in http://people.apache.org/builds/shale/m2-staging-repository. snip/ Ah, thats confirmation for one of my questions in the master pom thread. Because each release needs to be staged separately, the entire directory should be moved elsewhere sooner or later. I'd suggest moving it underneath wherever you're staging the assemblies for the vote. snap/ That directory (the staging repo) seems currently empty (has some directories, but they are empty). Maybe I will clean it for good measure before I start with the master pom (if I have the Unix perms). We'll probably move it to the ~ where any assemblies get posted. One other thing... I think we'll need to branch for releases. Continuum [1] is building from the trunk, so changing the version number to a non-snapshot will cause it to build and deploy those jars to the staging repo based on the configuration in the pom. Sounds like we need a 1.0 branch in any case, so this shouldn't be an issue. snip/ OK, if everyone's fine with that, I will create the 1.0 branch (called SHALE_1_0_x unless there are better suggestions) when we get closer to the release (after all 1.0.4-SNAP issues are resolved and the master pom is released etc.) -Rahul [1] http://myfaces.zones.apache.org:8080/continuum/servlet/continuum -- Wendy
Re: Release Status
On 12/15/06, Craig McClanahan [EMAIL PROTECTED] wrote: snip/ Re: you guys tag teaming on RM for Shale ... +1! :-). The wiki has a bunch of notes (mostly from Wendy) that I basically followed last time. A couple of things to watch out for: * The shale-master pom should be upversioned and released separately first, so we don't have to depend on a snapshot version of it snap/ Yup, I'll get to this, have a question first (probably deserves a new thread -- in a few minutes). * The parent pom has maven-javadoc-plugin and maven-source-plugin commented out for quicker development builds ... we'll want them for a release build. * There's a bunch of other commented out cruft that we might as well get rid of too. snip/ +1 to removing pom cruft (we can recover it from SVN history, and add back later if needed). * The details of how we can stage the actual bits to be voted on are likely to be slightly different ... but the key principle is that we want to be able to examine the actual bits being proposed (i.e. with a 1.0.4 version number, not an RC suffix) for the actual vote. Rahul's getting used to this on Commons releases :-). * Don't forget to tag the repository snap/ Sounds like reasonable things to do :-) We even have a staging repo defined in the master pom (thanks Wendy) which we should use for this. After the release, I'm also suggesting that we hold off on major changes to the repository until we talk about my earlier proposal to branch at this point and start working on 1.1 in the trunk, giving us the ability to do bugfix and/or security releases to the 1.0 branch without polluting it with new features. With SVN its easy to change our minds about whether the tag is under tags or branches, but I'd like to see us formalize that decision before getting active again. snip/ OK by me. -Rahul Craig
Re: svn commit: r487741 - in /shale/framework/trunk: shale-dialog-basic/src/main/java/org/apache/shale/dialog/basic/ shale-dialog-scxml/src/main/java/org/apache/shale/dialog/scxml/ shale-dialog/src/ma
On 12/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: craigmcc Date: Fri Dec 15 16:51:06 2006 New Revision: 487741 URL: http://svn.apache.org/viewvc?view=revrev=487741 Log: Refine the dialog framework APIs as a foundation for improving handling of browser navigation buttons: * Provide an escape hatch (getOpaqueState/setOpaqueState) such that a DialogContext implementation can optionally request that additional information be saved and restored with each JSF component tree that is rendered. There is a restriction that any such opaque state data must be Serializable. * Modify the two existing implementations to obey the updated API contract,but otherwise do nothing at the moment. * Refactor DialogPhaseListener a bit: - Make Constants.CONTEXT_ID_ATTR a private constant in this class. This information is a private implementation detail. - Create a private beforeRenderResponse() method, parallel to the existing afterRestoreView() method, in case we have to deal with more phases later. These are private APIs, so no disruption of apps can occur - Implement the saving and restoring of opaque data, if requested by the DialogContext implementation. If saved, it will be stored as another generic attribute on the view root component, but (again) this is an implementation detail not visible to callers. SHALE-61 snip/ The last experiment I did on this a while ago (link in JIRA), I was able to recover by trying to map the incoming view ID to the state ID (using an adhoc scheme) before proceeding in the dialog. The opaqueState addition is clearly better for this -- I think only the state ID String should be enough for the Commons SCXML impl (ofcourse, String may not hold for all dialog imps). I plan on digging into this towards filling up the shale-dialog-scxml bits early next week (Mon/Tue). The subdialog issue doesn't exist in the Commons SCXML impl (its one machine, rather than a stack of machines at runtime) -- ofcourse, the downside is that IDs in the parent and subdialog need to be unique (there are a few best practices to mitigate that, plus the next WD may have other recommendations regarding this, IIUC). -Rahul
[master-pom] scpexe:// URLs?
Before we get to the master pom release: Can we consider using scpexe:// URLs, or providing some way to do that? As it stands, scp:// URLs don't work for me when I'm traveling (and most of Dec. is travel). Background [1]. Before getting to the soution, it would help to get data points from folks who work with scp:// (does scpexe:// work, is it slower etc.). If it helps, heres a test project foo [2] I was playing with to test various wagon configs -- please change the test.repo server (will need an addition in settings.xml for it) URL to point to your ~ (instead of mine) if you decide to try it ;-) -- and do a: mvn -Ptest deploy Suggestions? -Rahul [1] http://marc.theaimsgroup.com/?t=11656079881r=1w=2 [2] http://people.apache.org/~rahul/wagon-test/
Re: svn commit: r487741 - in /shale/framework/trunk: shale-dialog-basic/src/main/java/org/apache/shale/dialog/basic/ shale-dialog-scxml/src/main/java/org/apache/shale/dialog/scxml/ shale-dialog/src/ma
On 12/16/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 12/16/06, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ The subdialog issue doesn't exist in the Commons SCXML impl (its one machine, rather than a stack of machines at runtime) -- ofcourse, the downside is that IDs in the parent and subdialog need to be unique (there are a few best practices to mitigate that, plus the next WD may have other recommendations regarding this, IIUC). The experiment I'm trying on the Basic impl is to declare, via a context init parameter, a strategy value for what getOpaqueData() should return, with the default being none as is the current behavior. I'm looking at a couple of possible strategies: snap/ Interesting, I actually gave a thought to (similarly) having a way to have multiple behaviors as well (and have the app developer select one via the dialog-config for each dialog) but for some reason it didn't stick in my mind. At some point, I remember going so far as to think if it would be possible for the app developer to provide such a strategy impl his/her dialog(s) -- in addition to a small list provided -- but that seemed to involve too many details of the dialog impl. * Current state name (+ some way to tell if you crossed a subdialog boundary so you can throw an exception) * The entire stack of Position instances, which includes the data objects at each level, so unwinding and rewinding changes everything. An interesting question to contemplate is what should happen with event firing with our shiny new DialogContextListener interface. snap/ Indeed, I think a common paradigm will be: do stuff on entry / undo on exit. In which case, the onExit() from the previous view state and the onEntry() into the new view state (whose corresponding view user navigated to using browser buttons) should minimally be fired. WDYT? -Rahul
Re: svn commit: r487741 - in /shale/framework/trunk: shale-dialog-basic/src/main/java/org/apache/shale/dialog/basic/ shale-dialog-scxml/src/main/java/org/apache/shale/dialog/scxml/ shale-dialog/src/ma
On 12/16/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 12/16/06, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ Indeed, I think a common paradigm will be: do stuff on entry / undo on exit. In which case, the onExit() from the previous view state and the onEntry() into the new view state (whose corresponding view user navigated to using browser buttons) should minimally be fired. WDYT? That certainly seems reasonable. I don't know about calling onTransition() though ... it seems quite likely that the transition implemented by responding to the navigation-induced changes will identify an arc that does not actually exist in the state diagram. snap/ I agree, no onTransition() makes sense to me. -Rahul
Re: svn commit: r487741 - in /shale/framework/trunk: shale-dialog-basic/src/main/java/org/apache/shale/dialog/basic/ shale-dialog-scxml/src/main/java/org/apache/shale/dialog/scxml/ shale-dialog/src/ma
On 12/16/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 12/16/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 12/16/06, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ Indeed, I think a common paradigm will be: do stuff on entry / undo on exit. In which case, the onExit() from the previous view state and the onEntry() into the new view state (whose corresponding view user navigated to using browser buttons) should minimally be fired. WDYT? That certainly seems reasonable. I don't know about calling onTransition() though ... it seems quite likely that the transition implemented by responding to the navigation-induced changes will identify an arc that does not actually exist in the state diagram. snap/ I agree, no onTransition() makes sense to me. snip/ The more I think, I'm not sure. In any case, will require us to have good docs for onTransition() in context of browser nav buttons! -Rahul
Re: Release Status
On 12/13/06, Greg Reddin [EMAIL PROTECTED] wrote: My project at work is finally in a place where we really need to use Shale :-) The 1.0.3 release does not work out of the box for us because we are using MyFaces 1.1.5 and Shale 1.0.3 depends on MyFaces 1.1.1. Shale 1.0.4-SNAPSHOT does not. So I started looking to see where we stand on publishing a release. snip/ In terms of 1.0.4-SNAP JIRA issues, I will be fixing SHALE-348 this weekend once I'm done traveling -- that leaves us with SHALE-61. I dropped the ball on that, and ATM I don't think there is any concrete proposal towards it. At some point, I'd like to RM a Shale release so I'm aware of all the minutiae. If you guys are OK with it, now is as good a time as any (though the scp:// m2 server URLs don't work for me). -Rahul
Re: Release Status
On 12/15/06, Greg Reddin [EMAIL PROTECTED] wrote: On Dec 15, 2006, at 10:38 AM, Rahul Akolkar wrote: In terms of 1.0.4-SNAP JIRA issues, I will be fixing SHALE-348 this weekend once I'm done traveling -- that leaves us with SHALE-61. I dropped the ball on that, and ATM I don't think there is any concrete proposal towards it. It looks like code has been checked in for SHALE-61, but maybe it just needs to be tested? snip/ No, don't think its been addressed completely. At some point, I'd like to RM a Shale release so I'm aware of all the minutiae. If you guys are OK with it, now is as good a time as any That's funny. I was going to volunteer too :-) Maybe we can tag team it. snap/ Sure, let me know what bits you think I can help with. -Rahul Greg
Re: Release Status
On 12/15/06, Greg Reddin [EMAIL PROTECTED] wrote: On Dec 15, 2006, at 10:38 AM, Rahul Akolkar wrote: In terms of 1.0.4-SNAP JIRA issues, I will be fixing SHALE-348 this weekend once I'm done traveling -- that leaves us with SHALE-61. ... also SHALE-211 [1]. I'm guessing we can close that one. Any objections? snip/ Resolve it, at worst it will get re-opened. Its shouldn't affect the release anyway, IMO. -Rahul Greg [1] https://issues.apache.org/struts/browse/SHALE-211
Re: svn commit: r482364 - in /shale/framework/trunk: shale-dialog-basic/src/main/java/org/apache/shale/dialog/basic/ shale-dialog-scxml/src/main/java/org/apache/shale/dialog/scxml/ shale-dialog/src/ma
On 12/4/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 12/4/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 12/4/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: craigmcc Date: Mon Dec 4 13:25:07 2006 New Revision: 482364 URL: http://svn.apache.org/viewvc?view=revrev=482364 snip/ This (and r482418) should be marked against SHALE-351 instead. I made the same mistake in r482449. If we care enough, I can try to edit the logs. I'm actually more interested in getting the svn log messages into the corresponding issues, but that feature has been turned off for a while on our JIRA instance :-(. Oh well, at least we can still build the recent changes part of the release notes off the target milestone field. snip/ Doesn't seem to be off anymore. Our bungled log messages have landed in SHALE-251 (not sure that can be remedied after the fact like the log): http://issues.apache.org/struts/browse/SHALE-251?page=all My favorite issue to check whether this is working is SHALE-310 (since its longstanding and has somewhat regular commits) -- it seems to be dutifully grabbing the svn logs. -Rahul Craig -Rahul
Re: svn commit: r482364 - in /shale/framework/trunk: shale-dialog-basic/src/main/java/org/apache/shale/dialog/basic/ shale-dialog-scxml/src/main/java/org/apache/shale/dialog/scxml/ shale-dialog/src/ma
On 12/4/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: craigmcc Date: Mon Dec 4 13:25:07 2006 New Revision: 482364 URL: http://svn.apache.org/viewvc?view=revrev=482364 Log: First round of supporting events when DialogContextManager.create() or DialogContextManager.remove() is called. You can now register listeners of type DialogContextManagerListener on the DialogContextManager instance. One remaining FIXME is to make it possible to be notified when DialogContextManager instances themselves are placed in and out of service -- since these instances are typically a session scoped managed bean, we need to do something interesting in order to fire the necessary events. snip/ SHALE-251 snap/ This (and r482418) should be marked against SHALE-351 instead. I made the same mistake in r482449. If we care enough, I can try to edit the logs. -Rahul
Re: Aquiring the Shale source
On 11/28/06, Niall Pemberton [EMAIL PROTECTED] wrote: The Aquiring Shale section on the building page points to the Struts download page (and mentions the struts subversion repository) for checking out the source: http://shale.apache.org/building.html snip/ Thanks, should be fixed [1] by the run tonight. -Rahul [1] http://svn.apache.org/viewvc?view=revrevision=480284 Niall
Re: [jira] Resolved: (SHALE-337) Unable to use redirects with dialogs
On 11/19/06, Rahul Akolkar [EMAIL PROTECTED] wrote: (replying to dev, though I think these get picked up in JIRA eventually) On 11/17/06, Craig McClanahan (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/struts/browse/SHALE-337?page=all ] Craig McClanahan resolved SHALE-337. Fix Version/s: 1.0.4-SNAPSHOT Resolution: Fixed Improvement completed in nightly build 20061118. You can now declare, in your dialog-config.xml file for the basic implementation, that transitions to a particular view should be done with a redirect instead of the normal call to ViewHandler.createView(). For backwards compatibility, and philosophical compatibility with standard JSF navigation, ViewHandler.createView() is the default. The underlying mechanism of recognizing a dialog id request parameter is built in to shale-dialog's phase listener, so it would be possible for the shale-dialog-scxml implementation to leverage this approach as well, once it was determined how to represent the request for a redirect in an SCXML configuration file. snip/ Probably a shale:redirect / custom SCXML action, so its similar to the JSF redirect/ (prefix dev choice as with JSP taglibs). I'll take a stab beginning of next week (before the long weekend travel kicks in). snip/ Done. -Rahul
Re: svn commit: r473638 - in /shale/framework/trunk/shale-dialog-basic: ./ src/main/java/org/apache/shale/dialog/basic/ src/main/resources/META-INF/
On 11/14/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 11/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: snip/ AHA ... just figured out what we are doing differently. The shale-dialog-basic library registers two resources (embedded in the jar file) for the 1.0 and 1.1 DTDs of a dialog configuration resource. The shale-dialog-scxml library does not (currently) have such a thing. If I comment out the registrations (temporarily forcing Digester to go out to the Internet to resolve them), I can undeploy successfully on 5.5.20. snap/ Cool :-) I'll port the rest of the changes over to dialog-scxml in the next couple of days, since other than the JCL and BeanUtils cleanups, I'm also interested in having the initialization bits at startup/deploy, rather than first access. snip/ Done. -Rahul -Rahul
Re: svn commit: r473638 - in /shale/framework/trunk/shale-dialog-basic: ./ src/main/java/org/apache/shale/dialog/basic/ src/main/resources/META-INF/
On 11/10/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: craigmcc Date: Fri Nov 10 20:16:19 2006 New Revision: 473638 URL: http://svn.apache.org/viewvc?view=revrev=473638 Log: Partial fix for cleaning up static resources at application shutdown (SHALE-274) for the basic implementation. This took several changes: snip/ Modified: shale/framework/trunk/shale-dialog-basic/pom.xml URL: http://svn.apache.org/viewvc/shale/framework/trunk/shale-dialog-basic/pom.xml?view=diffrev=473638r1=473637r2=473638 == --- shale/framework/trunk/shale-dialog-basic/pom.xml (original) +++ shale/framework/trunk/shale-dialog-basic/pom.xml Fri Nov 10 20:16:19 2006 @@ -40,6 +40,23 @@ /dependency dependency +groupIdcommons-logging/groupId +artifactIdcommons-logging/artifactId +/dependency + +dependency +groupIdjavax.servlet/groupId +artifactIdjsp-api/artifactId +scopeprovided/scope +/dependency + snap/ Why jsp-api here? -Rahul +dependency +groupIdjavax.servlet/groupId +artifactIdservlet-api/artifactId +scopeprovided/scope +/dependency + snip/
Re: [jira] Resolved: (SHALE-337) Unable to use redirects with dialogs
(replying to dev, though I think these get picked up in JIRA eventually) On 11/17/06, Craig McClanahan (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/struts/browse/SHALE-337?page=all ] Craig McClanahan resolved SHALE-337. Fix Version/s: 1.0.4-SNAPSHOT Resolution: Fixed Improvement completed in nightly build 20061118. You can now declare, in your dialog-config.xml file for the basic implementation, that transitions to a particular view should be done with a redirect instead of the normal call to ViewHandler.createView(). For backwards compatibility, and philosophical compatibility with standard JSF navigation, ViewHandler.createView() is the default. The underlying mechanism of recognizing a dialog id request parameter is built in to shale-dialog's phase listener, so it would be possible for the shale-dialog-scxml implementation to leverage this approach as well, once it was determined how to represent the request for a redirect in an SCXML configuration file. snip/ Probably a shale:redirect / custom SCXML action, so its similar to the JSF redirect/ (prefix dev choice as with JSP taglibs). I'll take a stab beginning of next week (before the long weekend travel kicks in). -Rahul
Re: Navigating from One SCXML dialog to another SCXML dialog in shale
On 11/16/06, THOMAS, JAYANT (SBCSI) [EMAIL PROTECTED] wrote: Thanks, Iam using the dialog2 implementation inside shale, can I do the same. snip/ Yup, should do, dialog2 was the sandbox moniker, its now the shale-dialog module (and the two impls - shale-dialog-basic and shale-dialog-scxml), part of the shale-framework-* builds [1]. IIRC, the white box nature referred to below was clarified post v0.5, so dangling target references might need the Commons SCXML nightlies [2] (trunk has test cases that verify the particular behavior under discussion here). If you have further questions, please ping the user list (Shale or Commons, as you find appropriate). Thanks. -Rahul [1] http://people.apache.org/builds/shale/nightly/ [2] http://people.apache.org/builds/jakarta-commons/nightly/commons-scxml/ Thanks Jayant -Original Message- From: Rahul Akolkar [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 15, 2006 7:36 PM To: dev@shale.apache.org Subject: Re: Navigating from One SCXML dialog to another SCXML dialog in shale On 11/15/06, THOMAS, JAYANT (SBCSI) [EMAIL PROTECTED] wrote: Thanks, That is what I want , say for example I might have a bunch of higher level states from where at certain point I can navigate to child states defined in another xml like popup.xml, it will be nice If I can navigate from Wizard to popup by saying something like #popup/statename in the state transition logic of wizard itself. I hope this is possible !! snip/ If using the Commons SCXML dialogs impl, this is possible. In fact, you don't even need to use '#popup' (at the cost of implying unique IDs for states when subdialog state machines are pulled in via 'src' attribute -- see subdialogs bit here [1]). This has to do with the semantics of SCXML itself, which treats included state machines as white boxes (this differs from the basic impl) and thus, you can have dangling transition targets (as long as they're available in the included state machine -- or vice versa) as you mention above. Note that you don't even need to declare the included state machine as a dialog in the dialog-config.xml unless you plan on using it as a standalone dialog (at which point, the dangling unresolved transition target references will cause a parse time failure, if you choose to have them). -Rahul [1] http://shale.apache.org/shale-dialog-scxml/ snap/
Re: Navigating from One SCXML dialog to another SCXML dialog in shale
On 11/15/06, THOMAS, JAYANT (SBCSI) [EMAIL PROTECTED] wrote: Thanks, That is what I want , say for example I might have a bunch of higher level states from where at certain point I can navigate to child states defined in another xml like popup.xml, it will be nice If I can navigate from Wizard to popup by saying something like #popup/statename in the state transition logic of wizard itself. I hope this is possible !! snip/ If using the Commons SCXML dialogs impl, this is possible. In fact, you don't even need to use '#popup' (at the cost of implying unique IDs for states when subdialog state machines are pulled in via 'src' attribute -- see subdialogs bit here [1]). This has to do with the semantics of SCXML itself, which treats included state machines as white boxes (this differs from the basic impl) and thus, you can have dangling transition targets (as long as they're available in the included state machine -- or vice versa) as you mention above. Note that you don't even need to declare the included state machine as a dialog in the dialog-config.xml unless you plan on using it as a standalone dialog (at which point, the dangling unresolved transition target references will cause a parse time failure, if you choose to have them). -Rahul [1] http://shale.apache.org/shale-dialog-scxml/ Thanks Jayant -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Wednesday, November 15, 2006 1:06 PM To: dev@shale.apache.org Subject: Re: Navigating from One SCXML dialog to another SCXML dialog in shale On 11/15/06, THOMAS, JAYANT (SBCSI) [EMAIL PROTECTED] wrote: Hello All, Is it possible I can navigate from one scxml dialog to another scxml dialog in shale dialog scxmlconfig=wizard.xml name=wizard dataclassname=org.apache.shale.examples.test.dialog2.scxml.WizardData/ dialog scxmlconfig=popup.xml name=popup dataclassname=org.apache.shale.examples.test.dialog2.scxml.PopupData/ Say from Wizard.xml can I go to popup.xml in the sample. The example show 2 different sets of dialogs without any interrelation ship. Thanks Jayant Are you wanting to *have* a relationship between the dialogs, so that (for example) the popup dialog has access to both its own state and the state of the wizard? If so, there's a way to do this that works for both SCXML and basic dialog implementations. The documentation[1] includes a bit of information on how to start a dialog programmatically using the DialogContextManager.create() call. But there is a second variation of create() that accepts a parent DialogContext with which the child dialog should be associated ... it will be set as the parent property of the new DialogContext for the popup. There's example code that accomplishes this in both the shale-dialog-test-basic and shale-dialog-test-scxml test applications (you'll need to check out the sources directly from the SVN repository to get to this code, however). Craig [1] http://shale.apache.org/shale-dialog/index.html
Re: svn commit: r473638 - in /shale/framework/trunk/shale-dialog-basic: ./ src/main/java/org/apache/shale/dialog/basic/ src/main/resources/META-INF/
On 11/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: snip/ AHA ... just figured out what we are doing differently. The shale-dialog-basic library registers two resources (embedded in the jar file) for the 1.0 and 1.1 DTDs of a dialog configuration resource. The shale-dialog-scxml library does not (currently) have such a thing. If I comment out the registrations (temporarily forcing Digester to go out to the Internet to resolve them), I can undeploy successfully on 5.5.20. snap/ Cool :-) I'll port the rest of the changes over to dialog-scxml in the next couple of days, since other than the JCL and BeanUtils cleanups, I'm also interested in having the initialization bits at startup/deploy, rather than first access. -Rahul
