Re: [Invitation To Design Discussion] - The Shale Dialog Manager Feature
On 8/21/06, Craig McClanahan [EMAIL PROTECTED] wrote: If you have tried out the dialog manager feature of Shale, you're probably well aware that it has some limitations and bugs. Indeed, I see improving this as the most important thing to tackle next. In reviewing the outstanding bug reports, it looks like we will need to rearchitect the current implementation. That means now is a good opportunity to review the requirements that the feature tries to meet, as well as evaluate a few implementation approaches, before we tackle the code itself. To that end, I've set up a wiki page[1] where we'll accumulate current thinking. snip/ Great, this interests me quite a bit :-) I'll make some comments on there later today or tomorrow. Not sure what the protocol is here, for user comments, but I'll prefix with [Rahul] for some such, for good measure. -Rahul [1] http://wiki.apache.org/shale/DialogManagerFeature [2] http://shale.apache.org/mail-lists.html
Re: Test 1.0.3 Artifacts (Round 2)
On 8/23/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/23/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 8/20/06, Sean Schofield [EMAIL PROTECTED] wrote: snip/ So my proposal is to involve everyone in the beta testing but do not distribute the final version to vote on so we can prevent mass confusion. If non committers want to participate they can build from the *tagged* svn version (not the trunk) and they do so at their own risk. snip/ Makes sense, going a step ahead, if a committer could generously post (rather than deploy) the bits in their personal webspace (rather than a maven snapshot repository, which presumably is where folks can unknowingly obtain the premature artifacts from) -- that would lower the barrier for participation, which is a good thing IMO. Now that we're building with Maven2, there are two kinds of things being deployed: * Release artifacts (bundled-up versions of the sources and compiled code, essentially like what the nightly builds produce) * Maven artifacts (jars and poms that need to be published into a Maven repository to be accessible). For the former, I did indeed do what Rahul suggests ( http://people.apache.org/~craigmcc/shale-proposed-release-1.0.3 but this is going away now that it's been completed), and that was part of the please test message to the dev list. snap/ Yup. For the latter, it wouldn't really make sense to set up yet another Maven2 repository in the release manager's personal web space ... the http://people.apache.org/repo/m2-snapshot-repository exists for this purpose. Indeed, the nightly build process has been posting 1.0.3-SNAPSHOTbuilds of these poms and jars all along (and, this is where the initial 1.0.3 test builds were posted). So, if you've been using 1.0.3-SNAPSHOT and wanted to try out 1.0.3, you'd need only switch the version number in your dependencies and you'd get the right stuff automatically ... no need to configure yet another repository entry for the temporarily posted bits. snip/ I tried to be careful in phrasing that, but didn't have much success ;-) Ofcourse, setting a m2 repository in personal webspace will be no fun (and a waste of time), but just posting the artifacts there (not in any particular repository layout) might be possible. For simplicity, lets say we have a simple project which produces just one artifact, foo.jar (yes, I oversimplified!). I can do a mvn compile and scp foo.jar (with sums and sigs) to ~rahul. If folks think its OK (they will have to deploy manually to local repo), we deploy to the remote repo(s) of choice. I claim that the extra effort required to manually deploy the artifacts in the local repo (by folks who are testing it) actually works in our favor, since there is little chance to accidently acquire the artifact (as against the apache snapshot repos, which are fairly well-known) and thereby, forget to replace it with the final v1.0.3. -Rahul Craig -Rahul Sean
Re: [dialog] Get rid of subdialogs
On 8/24/06, Craig McClanahan [EMAIL PROTECTED] wrote: snip/ In my ideal world scenario, we'll be able to rebuild things on the inside, with minimal-to-none impact on how an application developer uses it. However, I'm not convinced that goal is actually achievable, if we're going to have a dialog infrastructure that meets the functional requirements we've outlined. Even if it is not totally possible, however, I'm a fan of the way dialogs are currently configured, and would like to keep as much of that as possible, even if we did something radical like used Commons SCXML as the execution engine under the covers (betcha Rahul just perked up :-) -- things like that should be on the table at this point, as far as I can see. snap/ Yes, that draws my attention, not (only) because I'm a Commons SCXML developer, but because I believe this is the right way moving forward for Shale dialogs (I'll articulate in detail in another thread). No doubt that backwards compatibility should be maintained as far as possible. To use Commons SCXML to also support the current dialog notation, three approaches come quickly to mind: 1) Run a XML tranform under the hood (possibly tricky, since dialog-configs can contain multiple dialogs). 2) Write a specific digester that can map dialog-config.xml to the Commons SCXML model package [1]. 3) Do a Java object mapping (basically walk the object graph) of the Shale object model to a Commons SCXML one. Any other ideas? Any preferences? -Rahul (long, possibly fragmented URL below) [1] http://jakarta.apache.org/commons/scxml/apidocs/org/apache/commons/scxml/model/package-summary.html Craig
[dialog] Using SCXML to describe Shale dialogs
I'd like Shale to support both the current dialog notation and SCXML as stated here [1], and both can use the same underlying engine. The current dialog notation by virtue of being the incumbent, and SCXML because: * SCXML is a well-defined distillation of all variants of state machine theory. Its roots are with classical state chart theory (Harel state tables) and it aligns with latest UML standards (UML 2.0). It brings to the table most essential features of generic state machines. Shale dialogs currently provide a subset of those features. * As we look at prior art, we see different XML vocabularies doing the same (similar) things. Shale dialogs, SWF, Seam PageFlows, others. In an ideal world, we strive towards standardization (we like JSF :-) -- and the W3C has traditionally worked with markup languages. * The SCXML vision is more of a client-side statement, and agreed, its not obvious at this point. Pending success in browser adoption, it is perceived to drive behavior on graphical and speech browsers (add alignment with multi-modal standards as another plus) -- the advantage then is being able to draw a circle around part of my state machine diagram and consume that bit at will on either the client or server; should be a joy for MDD and programming model enthusiasts alike. * The tooling aspect gets an immediate boost by virtue of UML2 alignment, there are plugins (none open-source yet) that can transform state chart diagrams into SCXML documents. That means if you really dislike XML, you'd still be OK ;-) Thats important, but somewhat abstract. Concretely: * We know its doable [2], I've been using it (on a slightly dated distro that I'll be happy to bring upto date). * It satisfies the relevant requirements from a notation perspective as outlined on the DialogManagerFeature wiki page [3]. From the mandatory requirements, I see 1 through 7 as more of notation requirements, and hence, particularly relevant here. * Everything that Commons SCXML needs (Digester, JCL, EL) is already used by Shale dialogs (or provided by the container). No new transitive depedencies. * Commons SCXML has been released. Earlier, sandbox code was simply a showstopper, IMO. * It will be explicit developer choice. The SCXML NavigationHandler that gets plugged into Shale dialogs (so you can use SCXML documents to describe Shale dialogs) can only be configured in the application (or otherwise) faces-config. There is no way to mistakenly turn on that switch, so backwards compatibility is fully retained. New applications, OTOH, get a choice. -Rahul [1] http://marc.theaimsgroup.com/?l=struts-devm=112900158004770w=2 [2] http://jakarta.apache.org/commons/scxml/usecases/scxml-in-shale-dialogs.html [3] http://wiki.apache.org/shale/DialogManagerFeature
Re: Review Core JSF coverage of Shale dialogs?
On 8/24/06, David Geary [EMAIL PROTECTED] wrote: Would anyone like to review material on Shale dialogs from the upcoming 2nd ed of Core JSF (about 15 pages)? I have an example with a Bill Pay dialog that has a Wire Transfer subdialog. The data entered into the subdialog is incorporated into the enclosing dialog's data, so it's pertinent to our current dialog discussion. snip/ I see you have many offers already ;-) If you want to please the MDD crowd (and there is value in that IMO), you might want to sketch out some state machine diagrams (if you haven't already). If you post the entire dialog-config (I think the one you posted is incomplete), I can draw'em up in Rational if you want. For instance, here is the Shale usecases log on / edit profile example: (long, possibly fragmented URLs) http://jakarta.apache.org/commons/scxml/usecases/shale-dialogs/log-on-dialog.jpg http://jakarta.apache.org/commons/scxml/usecases/shale-dialogs/edit-profile-dialog.jpg -Rahul david
[dialog] Styling the dialog-config to SCXML
As step 0 of SHALE-263 [1], here [2] is an initial cut of the stylesheet for producing the needed SCXML documents from Shale dialog configuration files. That directory [2] also contains the result of styling the dialog-config.xml that comes with the Shale usecases application (log on / edit profile). Probably easiest to try via the command line: %java org.apache.xalan.xslt.Process -IN dialog-config.xml -XSL dialogconfig2scxml.xsl -OUT scxml-config.xml Caveats: * To produce multiple output documents, we either need processor specific XSLT extensions (if on XSLT 1.0, which pretty much all of us are) or we need a XSLT 2.0 processor. I'm currently using a xalan-specific extension (xalan:write), so the above will only work on JDK 1.4 (or 1.5 with xalan on classpath -- only if Sun 1.5). Will explore better solutions, wanted to get the initial cut of the stylesheet out there. * Quick sketch, may not be bullet proof yet (if you can try it out on your dialog-configs that'd be great). Notes about style results: * The event name faces.outcome and the variable name outcome are arbitrarily chosen (its the job of the SCXML NavigationHandler to trigger the event, we can choose whatever names we like) * The SCXML invoke element in view states can go away. It has to do with the state-activity separation in state charts. There are multiple ways to achieve this (some do not involve adding to the XML vocabulary -- similar to the ViewResolvers used in Spring MVC -- thats more of a C/C approach). I'm not proposing that new applications use invoke. -Rahul [1] https://issues.apache.org/struts/browse/SHALE-263 [2] http://people.apache.org/~rahul/shale/style-dialogs/
Re: [dialog] Name attribute best practice
On 8/25/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/25/06, Rahul Akolkar [EMAIL PROTECTED] wrote: I would like to propose a best practice for the name attribute used in various bits of the XML vocabulary for Shale dialogs that recommends restricting these to alphanumeric characters (no spaces etc.) I suppose there's a technical reason for this ... I really like the readability of these if we can keep them and it was why I chose name instead of id' for that attribute in the first place. snip/ Yes, the state IDs are meant to be IDREFs in space separated lists on transition targets when the SCXML parallel element is used, where it will be possible to have more than one transition target, as long as the targets belong to the regions of the same parallel. Ofcourse, when using a space separated list, having spaces in individual tokens will throw a wrench in the works. -Rahul Craig Commons SCXML v0.5 is accomodating in that it will allow spaces for state IDs (which is what the name attribute maps to) but there are good reasons why we will shy away from this in some future release be it at the cost of some legibility (driven by changes to that spec draft). I will produce a patch over the weekend such that the usecase application follows this best practice (ofcourse, unless someone has a good reason why we can't do without spaces here). -Rahul
Re: [dialog] How to use a common view with different dialog managed beans?
On 8/25/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 8/25/06, Paul Spencer [EMAIL PROTECTED] wrote:
An advantage with the current dialog.data bean is that it allows a the
use of a common view when the underlying data objects are different. How
would this be done with dialog managed beans?
As an example the AbstractPayment class has a CreditCard and a Check
implementation. Both the Pay By Check and Pay by CreditCard share a
common view that collects the billing address information. In the
current implementation, that view uses #{dialog.data.billingZipCode} to
pass the billing zip code regardless of the actual class. With dialog
managed beans their will be a check and creditCard bean so how would the
billing zip code be referenced in the common view? So unless their is a
way to alias the beans in the dialog configuration, the billing address
view can not be shared.
You are limited to a single instance of #{dialog.data}, but that bean itself
can have properties that are, in fact , beans ... and you can nest as deeply
as you like. So, your Payment class (the one you use as the data bean for
one of the processes could have a property of type AddressBean, and you
could therefore have binding expressions like #{dialog.data.address.zipCode}
to talk to it. The only collaboration that would be needed here is that all
of the 'outer data beans that used an AddressBean would need to store it
under the same property name. You don't have to worry if the type of the
data bean is different, because the EL machinery takes care of all of that
for you.
snip/
And IIU your class diagram correctly, having the zip in the
AbstractPayment automatically takes care of this. All you would then
need to do is populate #{dialog.data} with either the CreditCard or
the Check bean via the setup action state in the corresponding
dialog.
-Rahul
Paul Spencer
Craig
Re: [dialog] Using SCXML to describe Shale dialogs
On 8/25/06, Sean Schofield [EMAIL PROTECTED] wrote: I have few initial concerns after looking over the excellent documentation and examples on the Commons SCXML site. So far, my concerns are as follows: 1.) I'm not wild about having to run an XSL transform on dialogs during compile time snip/ Yes, sub-optimal, though an exercise in the following: * Making sure the dialogs can actually map to SCXML * Support two XML vocabularies with one engine but the SCXML approach to configuring dialogs seems to involve excessive XML if you're not using UML. snap/ Correct. Character-to-character, it has higher verbosity. But, at the notation level, it does satisfy this -- simple things should be simple, other things should be possible. It does useful things, to name a few: * Allow executing content on a transition * Allow arbitrary levels of recursion in composite states (without breaking into a subdialog) * Allow parallelism Don't get me wrong. snip/ Please don't worry about that. All constructive criticism is highly welcome, and can only benefit all projects involved. So, please don't hold back ;-) Its a very cool concept but I'm not sure going from UML to dialog config is the most important feature in a dialog solution. snap/ I do this for every dialog. I do understand others may not. 2.) Each dialog needs its own SCXML file. In one extreme use case where you have a ten step dialog and you want to have individual single step dialogs for each of ten steps, you'd need 11 SCXML files. snip/ Correct, valid point. As part of this process, we can explore ways to alleviate this, but nothing jumps at me right now. 3.) Global transitions need to be configured in each of the SCXML files (is that right?) snap/ The notations are very symmetric. If you would define global transitions in more than one dialogs, then you need them in more than one SCXML files. If you define them in one dialog, you need them in one SCXML file (and so on ...). As a bonus, SCXML gives you local transitions, global transitions and many layers in between (depending on how you nest the states -- again, this goes beyond the current dialog notation). While I realize these should be ideally coming from the UML, the reality is a lot of people will not be using SC to design their dialogs. I haven't made up my mind on SCXML - in fact I seem to be swinging back and forth. Even if we don't go with it right away, I think it merits further study (and a place in our sandbox.) snip/ As I've said before, and opened a JIRA ticket for it, I'm happy to take this experiment to some sort of conclusion over the coming weeks. There is always going to be inertia when a new notation comes into picture. IMO, the current notation definitely deserves credit and does its job given the usecases its seen till date. However, when I look out into the distance, I see many more reasons why supporting SCXML makes sense as outlined on the top of this thread. Its a traveling weekend, see you on its other side. -Rahul I'm curious as to what others think. Sean snap/
Re: Is Commons SCXML 0.5 published in a Maven repository somewhere?
On 8/25/06, Craig McClanahan [EMAIL PROTECTED] wrote: Rahul, I'm trying to set up a quick Shale Sandbox project where we can experiment with the SCXML integration we've been discussing on the Shale Dev list. snip/ Cool, should be fun. I notice that you've released version 0.5, but I don't see the JAR file available in any Maven repository anywhere. snap/ I did put it in the m1-rsync repo [1] and it seems to have been mirrored on ibiblio [2] but last time I checked I couldn't get it into another m1 build so I might need to ping the Maven folks about that. And nothing m2 yet. Could you publish it to the Apache snapshot repository at /www/people.apache.org/repo/m2-snapshot-repository on people.apache.org? If you need any help figuring out how/what to do just holler. snip/ Sure, my m2 is just getting started, but I should be able to read my way through it. If not, I'll take you up on the offer, thanks! (I'm on the road till Sun evening). -Rahul [1] http://people.apache.org/repo/m1-ibiblio-rsync-repository/commons-scxml/ [2] http://www.ibiblio.org/maven/commons-scxml/ In the mean time, I'll build 0.5.1-SNAPSHOT from source and install it locally, but it'll help other people experimenting with this code not to have to do that. Craig
Re: [dialog] Progress on weekend experiments
On 8/30/06, Craig McClanahan [EMAIL PROTECTED] wrote: snip/ I'll be able to pick this up tonight and play with it. Can someone remind me of the syntax to change the eol properties on the existing files? snap/ svn propset, see: http://svnbook.red-bean.com/en/1.0/re23.html -Rahul Craig
Re: [dialog] Requirement: Uncaught exception ends dialog?
On 8/30/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/28/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Correct, that schema is immutable as far as we're concerned. And for obvious reasons, since we can't really model an on-exception transition attribute in a UML state chart (its too Java specific) or in classical state chart theory either. But what it can be treated as, is simply an event whose name is the FQN of the exception (this is what we've been promoting as the best practice, especially in the realm of SCXML custom actions, where such executable content may throw derived events). Is an FQN unambiguous compared to other possible event names? snip/ Yes, if done right. The best practice in event names is that, like package names, they imply a particular ontology, starting from the broadest to the narrowest using . as a separator. This is one of the reasons I chose the faces.outcome event name. In the end, the event names are decided by the user. As long as the user has a naming scheme that is followed in the SCXML documents used for that usecase, we're fine. Another interesting usage of such a event naming scheme (which is probably not immediately obvious) is that it also works like a wildcard scheme (though this bit doesn't always translate well to the Java exception FQNs) i.e. if the following is a candidate transition: transition event=error.send ... / when an event error.send.targetunavailable is triggered, the above transition will be followed (since error.send.targetunavailable is considered to be a type of error.send due to the implication of an ontology). I suppose it could be if you disallowed . in any other kind of name. A couple of other thoughts on how one might express this: * An exception:FQN syntax that uses a prefix in the same spirit as entering a dialog through a logical outcome that has a special prefix. * Since the guard condition can be an expression, some concise way to evaluate an expression to see if an exception was thrown. snap/ Sure, these are other options. -Rahul Craig
Re: [dialog2] Advance failures and names
On 8/30/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/30/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Some notes from looking at the dialog2 sandbox modules: a) Dealing with failures in: Context#advance(FacesContext, String) It is possible that advancing a dialog might fail (say there is no such state defined as indicated by a transition target), and while many of these errors can be caught by static analysis and model checking tooling (indeed, Commons SCXML, for example will warn of many such errors at parsing time), how should the engine that gets plugged in report such an error, if one at all occurs? Doesn't make much sense to have a typed exception here since its going to bubble up to the handleNavigation() method without a throws clause. Some sort of logging would probably be appropriate. We could also define an event (in the JavaBeans sense, where you can register listeners) on the context class, so the app can choose to be notified when an exception occurs, and take whatever action *it* wants to take. snip/ Sounds good, I can take a stab at the JavaBeans listener if we want to do this (after the long weekend). Do we just want error notifications or progress notifications as well? NIT-PICKS (yes, I'm aware I'm nit-picking below ;-): b) In line with FacesContext, InitialContext, PageContext etc., should we rename the Context interface to DialogContext? Context seems way too generic and would make the variable declarations more readable, IMO. Also appropriate for me to point out that there is a Context interface in Commons SCXML but there was lot of time spent mulling over that name FWIW now. I think you're right ... it's hard to remember what kind of context you're talking about otherwise. I'll make this change when I import your shale-dialog2-scxml stuff tonight. (Gotta love refactoring engines in IDEs :-). How about Contexts though? DisplayContexts would be an obvious choice but the actual functionality of the class is a little more than just a cache of the active things. Maybe DialogContextManager? snap/ DialogContextManager sounds appropriate to me. -Rahul Craig
Re: [dialog2] Config init command
On 8/30/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/30/06, Rahul Akolkar [EMAIL PROTECTED] wrote: The init and destroy commands for the Shale dialog configs will need to have mods for dialog2 (atleast init). Should we copy them over to the sandbox so we can work with them? Need to be able to configure the parser. I actually finessed this on the legacy version, by reading the configuration stuff on demand. snip/ Yup, I used the same scheme in shale-dialog2-scxml on that one ;-), just wasn't sure if it was a sandbox thing. Will be a noticeable hit for the first dialog instantiation, depending on the size and number of dialogs. One thing I didn't like about the original pattern was these classes only got invoked if you happened to define the Shale application filter. I've been on a kick to make the various parts of Shale as self-configuring as possible, and this seemed like another opportunity. snap/ Makes sense, that way the only remaining thing that the application filter seems to be invoking is the deprecated remote stuff. -Rahul -Rahul Craig
Re: svn commit: r439525 - /shale/framework/trunk/shale-apps/shale-usecases/src/main/webapp/WEB-INF/dialog-config.xml
On 9/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: craigmcc Date: Fri Sep 1 19:57:25 2006 New Revision: 439525 URL: http://svn.apache.org/viewvc?rev=439525view=rev Log: Per discussion on the dev list, make dialog and state names omit embedded spaces. Modified: shale/framework/trunk/shale-apps/shale-usecases/src/main/webapp/WEB-INF/dialog-config.xml snip/ Ah, thanks! Could someone with appropriate JIRA permissions please resolve SHALE-267 [1] (as fixed)? The above commit takes care of that task/reminder. -Rahul [1] https://issues.apache.org/struts/browse/SHALE-267
Re: [sandbox] karma
On 9/6/06, Sean Schofield [EMAIL PROTECTED] wrote: Welcome aboard. I think Craig is the only one who can give you the access to the sandbox so we'll wait on him. snip/ Thanks for the welcomes ;-) (more than one) Its a fun time to be here. Craig has created the shiny new shale-sandbox svn auth group, so I should be all set there. -Rahul Sean On 9/5/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Just returning from a trip, and a few days behind on email, so sorry if I misunderstood anything about the sandbox karma proposal. It appears that it is now open to existing Apache committers. Reading this [1], I (username rahul) should express my interest in: * dialog2: The various dialog related bits in sandbox, things such as [2],[3],[4] and more * clay: Always been interested since its (vaguely) similar to something I was involved in [5], in a different application space -- hope to find time to play with it someday -Rahul [1] http://shale.apache.org/sandbox/ [2] https://issues.apache.org/struts/browse/SHALE-61 [3] https://issues.apache.org/struts/browse/SHALE-263 [4] https://issues.apache.org/struts/browse/SHALE-268 [5] http://jakarta.apache.org/taglibs/doc/rdc-doc/intro.html
Re: Objection to (part of) r440205
On 9/9/06, Craig McClanahan [EMAIL PROTECTED] wrote:
Sean's changes fo the dialog2 sandbox implementation in r440205 includes the
following change that I object to:
---
shale/sandbox/shale-dialog2/src/main/java/org/apache/shale/dialog2/faces/Dialog2NavigationHandler.java
(original)
+++
shale/sandbox/shale-dialog2/src/main/java/org/apache/shale/dialog2/faces/Dialog2NavigationHandler.java
Mon Sep 4 16:52:55 2006
@@ -135,6 +135,9 @@
+ context + ' with navigation to viewId '
+ viewId + ');
}
+if (viewId == null) {
+original.handleNavigation(context, fromAction, outcome);
+}
}
navigate(context, viewId);
My objection is on two grounds:
* Philosophically, navigation within a dialog should be self contained,
and attempts to navigate via an outcome not defined by the dialog
definition should be treated as an error condition. Otherwise, we're
going to find ourselves in situations when the actual navigation being
performed is non-deterministic ... it's based on what (if any) dialogs
called me as a subdialog, so I have to do a lot more searching to
find problems. It also makes static analysis of an application to
determine
whether all its outcome values are legal virtually impossible.
snip/
I'm in agreement with the above, and we cannot undermine the benefits
of static analysis -- we need that end-to-end approach from modeling
to generation to testing.
As a sidebar, there are practical considerations (such as global
navbars) that we should perhaps explore via sample dialogs in the
sandbox, and attempt to establish a set of best practice guidelines
for the same (such as mapping those to some end states?).
Although this particular change only delegates to the original
navigation handler if the last state executed returned null, the
stated justification for this action (delegate when we don't know
what the response means) does not match the reality here. In
particular, a null return from a state is a *deliberate* decision by
the dialog to stay on the current view id. That decision should be
respected.
snap/
I've always been seeing that change in light of Sean's earlier commit
r440216 [1]. This means that the legacy implementation returns null in
two cases, deliberately or on IllegalStateException in transition()
(which is masked into a null return).
* Technically, this particular change doesn't look like it will accomplish
anything anyway, because it is not followed by a return statement.
Instead, control will fall through to the call to navigate() anyway.
snip/
Indeed.
-Rahul
[1] http://svn.apache.org/viewvc?view=revrevision=440216
It seems like what we really want is the following change instead:
--- shale/sandbox/shale-dialog2
/src/main/java/org/apache/shale/dialog2/faces/Dialog2NavigationHandler.java
(original)
+++
shale/sandbox/shale-dialog2/src/main/java/org/apache/shale/dialog2/faces/Dialog2NavigationHandler.java
Mon Sep 4 16:52:55 2006
@@ -135,6 +135,9 @@
+ context + ' with navigation to viewId '
+ viewId + ');
}
+if (viewId == null) {
+return;
+}
}
navigate(context, viewId);
Alternatively, we could modify navigate() to just do nothing if the passed
viewId is null.
Craig
Re: [dialog2] Current status
(top-posting on purpose)
And no action states to stuff in dialog data makes things cleaner still !
As an aside, I've restored 1.4 source compatibility for the
shale-dialog2-legacy module. I believe that any module that doesn't
inherently need tiger features should stay at 1.4 source.
Can a list moderator allow ( rahul AT apache DOT org ) through please?
I'd expect the r442392 message [1] to get stuck in moderation. Thanks!
-Rahul
[1] http://svn.apache.org/viewvc?view=revrevision=442392
On 9/11/06, Craig McClanahan [EMAIL PROTECTED] wrote:
As I had hoped, I got the opportunity over the weekend to spend some
significant time hacking on the Dialog2 APIs (and the legacy version of the
implementation), and I'm getting pretty happy with the results. The test
program (shale-test-dialog2-legacy) includes scenarios for multiple windows
(both frames and a popup window running the same dialog), as well as a
parent-child popup scenario, and it seems we've addressed the majority of
the original issues on our requirements list[1]. The most important one
that remains to be considered is dealing with browser navigation buttons.
Nearly all of the dynamic behavior of a DialogContext are now encapsulated
in three public methods:
// Start the execution of this dialog, and proceed until
// a view needs to be rendered. Navigate to that view
// and return.
public void start(FacesContext context);
// Continue the execution of this dialog, using the
// specified logical outcome (returned by the action
// method that was executed for the previously rendered
// view) to drive the initial transition. Proceed until another
// view needs to be rendered. Navigate to that view
// and return.
public void advance(FacesContext context, String outcome);
// Stop the execution of this dialog prematurely. After
// this method returns, there wll be no active DialogContext
// instance associated with the current view.
public void stop(FacesContext context);
A DialogContext now also has an optional parent property, pointing at the
DialogContext for a different window or frame belonging to the same user.
(This is different from subdialogs, which performs nested dialog execution
for the *same* window). The classic use case is a popup window that needs
to be associated with a main window, and the popup needs to do things like
(a) pull data from the main window's data object, (b) do some computations
and/or interactions with the user, and (c) push some results back into the
main window's data object. The test application has an example of this, on
the second page, where you can use a mini-wizard to select
city/state/zipcode to be pushed back into the main window. NOTE - there are
two outstanding issues related to this test that should be finished off to
make it act more like a real app:
* JavaScript code to push client side updated values back into the main
window
(to correspond to what is happening on the server side data objects).
* JavaScript code to close the popup window when it is finished or
cancelled.
As an example of the simplicity of the new APIs, here's the final code to
cover one of Sean's use cases -- a menu command that can cancel an
in-progress dialog and start a different one.
public String checkout() {
// Cancel any currently active dialog
FacesContext context = FacesContext.getCurrentInstance();
DialogContext dcontext = (DialogContext)
context.getApplication().getVariableResolver().resolveVariable(context,
Constants.CONTEXT_BEAN);
if (dcontext != null) {
dcontext.stop(context);
}
// Start a new checkout dialog
DialogContextManager manager = (DialogContextManager)
context.getApplication().getVariableResolver().resolveVariable(context,
Constants.MANAGER_BEAN);
dcontext = manager.create(context, checkout);
dcontext.start();
return null;
}
Please give this code a whirl by building shale-dialog2,
shale-dialog2-legacy, and shale-test-dialog2-legacy in the sandbox. Note
that, at the moment, none of these APIs depend on the rest of Shale at all,
so they can be used on pretty much any JSF-based application that only needs
dialog management capabilities. I'm leaning towards keeping things that way
(moving towards a philosophy that Shale is a set of fine grained features
that can be used a la carte), unless we have compelling reasons to establish
a dependency.
Craig
PS: Now, on to getting the SCXML implementation up to date with the API
changes ...
Re: [dialog2] Current status
On 9/11/06, Craig McClanahan [EMAIL PROTECTED] wrote: snip-entire-email/ :-) PS: Now, on to getting the SCXML implementation up to date with the API changes ... snap/ Should be more or less there now. I've created a test app for the SCXML bits as well, all feedback on that is welcome. Can someone please confirm the integration tests work, I'm out of time (and please also point me to the wiki / web page or the mvn command to run those ;-) BTW, in split frame mode, both frames point to the same child dialog (popup) which probably needs a thought or two. -Rahul
Re: [dialog2] Current status
OT, sorry. On 9/14/06, THOMAS, JAYANT (SBCSI) [EMAIL PROTECTED] wrote: That will be a great idea, i.e. porting RDC to JSF I can help with this, snip/ Cool, if you post a proposal on the correct list, we can continue this conversation. -Rahul RDC + SCXML will be a excellent combination for developing speech applications. One thing iam not clear on is the Shale+SCXML engine integration architecture, I will try looking at the code. Thanks Jayant -Original Message- From: Rahul Akolkar [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 13, 2006 12:40 PM To: dev@shale.apache.org Subject: Re: [dialog2] Current status On 9/12/06, THOMAS, JAYANT (SBCSI) [EMAIL PROTECTED] wrote: Where Can I get this code, I would like to test it out, Also I am planning on using different markup language for different browsers , ie more focused on vxml and just simulator for HTML , looks like I have to create my own JSF components. snip/ Yes, I was interested in porting RDCs [1] to JSF, but am currently out of time for that. Should be a worthy exercise, since the RDC spirit is the only one that makes sense (to me) for VXML markup generation in a J2EE environment. Questions about RDCs, ofcourse, are off-topic on this list (the correct one would be taglibs-user@jakarta.apache.org, please feel free to ask there). Thinking for a minute what we'd get if this is done in conjunction with Shale, you'd have SCXML driving your voice dialogs in an individual view (RDC group container), and you have Shale driving cross-view navigation, where you can now choose SCXML. Thats makes for pretty, and recursive, MVC ;-) -Rahul [1] http://jakarta.apache.org/taglibs/doc/rdc-doc/intro.html
Re: Simplifying Framework Dependencies
On 9/12/06, Craig McClanahan [EMAIL PROTECTED] wrote: As Shale moves towards maturity, one of the usability issues on my mind is the set of dependencies that we currently mandate in shale-core and friends. snip/ The thread will be interesting in more than one ways ... in addition to the benefits of modularization and losing some of the direct dependencies for Shale, I expect to apply some of the lessons to other projects, which have similar dependencies and are also at 1.4. Generally, the content I snipped looked OK to me :-) -Rahul
Re: svn commit: r443481 - in /shale/sandbox/sandbox-dist: ./ pom.xml src/ src/assemble/ src/assemble/dist.xml
On 9/14/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 9/14/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 9/14/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: craigmcc Date: Thu Sep 14 14:34:35 2006 New Revision: 443481 URL: http://svn.apache.org/viewvc?view=revrev=443481 Log: Simple distribution module for the libraries that currently make up the Shale sandbox. The web applications will each be packaged individually. Added: shale/sandbox/sandbox-dist/ shale/sandbox/sandbox-dist/pom.xml (with props) shale/sandbox/sandbox-dist/src/ shale/sandbox/sandbox-dist/src/assemble/ shale/sandbox/sandbox-dist/src/assemble/dist.xml (with props) Added: shale/sandbox/sandbox-dist/pom.xml URL: http://svn.apache.org/viewvc/shale/sandbox/sandbox-dist/pom.xml?view=autorev=443481 snip/ Propchange: shale/sandbox/sandbox-dist/pom.xml -- svn:executable = * snap/ I think your svn client auto props for XML files needs eol-style (and could do without executable IMO). I've added what I needed for these two files. That's wierd ... I use the standard Linux command line client (version 1.3.0), and XML files are set for eol-style in my settings (~/.subversion/config), just like Java files are. And *nothing* is set to turn on executable. snip/ Hmm. Strange. -Rahul -Rahul Craig
Re: [jira] Resolved: (SHALE-293) Upgrade to MyFaces 1.1.4
On 9/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Yes, I did indeed build the framework first. snip/ OK, shale-parent should dictate the version. I svn up'ed everything and clean install'ed in sequence. -Rahul Hermod -Original Message- From: Rahul Akolkar [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 26, 2006 8:43 AM To: dev@shale.apache.org Subject: Re: [jira] Resolved: (SHALE-293) Upgrade to MyFaces 1.1.4 On 9/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi I am also getting an error when I try to build the sandbox componente from the top: [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.shale:shale-dialog2 POM Location: E:\Apache\Shale\sandbox\shale-dialog2\pom.xml Validation Messages: [0] 'dependencies.dependency.version' is missing for org.apache.myfaces.cor e:myfaces-api Reason: Failed to validate POM snip/ Did you mvn install framework first? (to install shale-parent changes) -Rahul Hermod snap/
Re: [jira] Resolved: (SHALE-293) Upgrade to MyFaces 1.1.4
On 9/26/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 9/25/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 9/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi I am also getting an error when I try to build the sandbox componente from the top: [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.shale:shale-dialog2 POM Location: E:\Apache\Shale\sandbox\shale-dialog2\pom.xml Validation Messages: [0] 'dependencies.dependency.version' is missing for org.apache.myfaces.cor e:myfaces-api Reason: Failed to validate POM snip/ Did you mvn install framework first? (to install shale-parent changes) That's the one I'm trying, and it's failing. snip/ Should go out to ibiblio (if thats why its failing). As a data point, I have no custom settings(.xml) on this machine. -Rahul -Rahul Craig Hermod
Re: [jira] Resolved: (SHALE-293) Upgrade to MyFaces 1.1.4
On 9/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi That was the exact procedure I followed after reading Wendy's posting about upgrading the pom to 1.4-SNAPSHOT. I looked into my local Maven repository, and it does not have a 1.4-SNAPSHOT of MyFaces. I suspect that it is bombing out on the Shale master pom for some reason before it actually gets to the phase ogf trying to download MyFaces. The message about dependencies.dependency.version' is missing for org.apache.myfaces.cor:myfaces-api might be the clue here. It might be an idea to look into what the master pom says about the dependency. snip/ The master POM [1] doesn't list any dependencies, so that seems unlikely. I believe you mean 1.1.4 of MyFaces Core artifacts? Those are released artifacts, not SNAPSHOTs. Again, not sure why you'd get a missing version message on myfaces-api from shale-dialog2 since the parent has chosen the version (1.1.4) which should simply continue to hold. -Rahul [1] http://svn.apache.org/repos/asf/shale/maven/trunk/master-pom/pom.xml Hermod -Original Message- From: Rahul Akolkar [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 26, 2006 8:50 AM To: dev@shale.apache.org Subject: Re: [jira] Resolved: (SHALE-293) Upgrade to MyFaces 1.1.4 On 9/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Yes, I did indeed build the framework first. snip/ OK, shale-parent should dictate the version. I svn up'ed everything and clean install'ed in sequence. -Rahul Hermod snap/
Re: [jira] Resolved: (SHALE-293) Upgrade to MyFaces 1.1.4
On 9/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Now it build (almost) ok. Got build errors on shale-test-dialog2-legacy: snip/ Thats a good sign. clean install shale-apps. Then retry sandbox. -Rahul Compiling 5 source files to E:\Apache\Shale\sandbox\shale-test-dialog2-legacy\ta rget\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure E:\Apache\Shale\sandbox\shale-test-dialog2-legacy\src\main\java\org\apache\shale \examples\test\dialog2\legacy\PopupData.java:[24,25] package javax.faces.model d oes not exist E:\Apache\Shale\sandbox\shale-test-dialog2-legacy\src\main\java\org\apache\shale \examples\test\dialog2\legacy\PopupData.java:[84,12] cannot find symbol symbol : class SelectItem location: class org.apache.shale.examples.test.dialog2.legacy.PopupData E:\Apache\Shale\sandbox\shale-test-dialog2-legacy\src\main\java\org\apache\shale \examples\test\dialog2\legacy\PopupData.java:[86,11] cannot find symbol symbol : class SelectItem location: class org.apache.shale.examples.test.dialog2.legacy.PopupData E:\Apache\Shale\sandbox\shale-test-dialog2-legacy\src\main\java\org\apache\shale \examples\test\dialog2\legacy\Popup.java:[21,27] package javax.faces.context doe s not exist .. Hermod
[dialog] 'data' instance variable
The code review tool flags the instance variable data (the dialog data) being declared as an Object, in relevant places in both the basic and scxml impl. While we do document the fact that dialog data should be Serializable, we do not enforce that in code. Any downside to changing the type of 'data' to Serializable? Also getting flagged for missing serialVersionUIDs, don't see them elsewhere either (except in clay). -Rahul
Framework artifact names
Here's the abbreviated reactor summary on the framework build: [INFO] Shale Test Framework [INFO] Shale Core Library [INFO] Shale Application Controller Support [INFO] Shale Clay Plugin [INFO] Shale Dialog Manager Integration [INFO] Shale Dialog Manager (Basic Implementation) [INFO] Shale Dialog Manager (SCXML Implementation) [INFO] Shale Remoting Support [INFO] Shale-Spring Integration [INFO] Shale View Controller Support [INFO] Shale Tiger Extensions [INFO] Shale Tiles Integration [INFO] Shale Validator Support We have frameworks, libraries, supports, integrations, extensions, plugins. * What in clay gives it a plugin status? * What differentiates support from say, library? * Integration means value-add based on an outside artifact, but why is shale-dialog an integration (we have a native impl)? Quibbling, but before someone asks me, I must ask you. How about ditching the library, support and plugin qualifiers? How does this look: [INFO] Shale Test Framework [INFO] Shale Core [INFO] Shale Application Controller [INFO] Shale Clay [INFO] Shale Dialog Manager [INFO] Shale Dialog Manager (Basic Implementation) [INFO] Shale Dialog Manager (SCXML Implementation) [INFO] Shale Remoting [INFO] Shale Spring Integration [INFO] Shale View Controller [INFO] Shale Tiger Extensions [INFO] Shale Tiles Integration [INFO] Shale Validator Integration -Rahul
Re: svn commit: r463684 - in /shale/framework/trunk: shale-application/src/main/java/org/apache/shale/application/faces/ shale-remoting/src/test/java/org/apache/shale/remoting/impl/ shale-test/src/mai
On 10/13/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 10/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: One caution on the unused imports warnings ... Checkstyle does not consider a javadoc comment like [EMAIL PROTECTED] Foo} to be a use, but Javadoc cannot create a correct link unless you either import this class (if it is not in the same package), or make it fully qualified. So, some of the unused imports are actually used :-). Could that be why I'm getting this? $ mvn site ... [INFO] Building Shale Dialog Manager (SCXML Implementation) [INFO]task-segment: [site] ... [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error during page generation Embedded error: Error rendering Maven report: Exit code: 1 - javadoc: warning - Error! javadoc: warning - com.sun.tools.javac.code.Symbol$CompletionFailure: file javax \servlet\jsp\el\FunctionMapper.class not found com.sun.tools.javac.code.Symbol$CompletionFailure: file javax\servlet\jsp\el\Fun ctionMapper.class not found snip/ Is the error in the shale-dialog-scxml module (as it seems from the above output)? If so, then this particular commit is unlikely to have caused that problem (since there were no mods to that module in this commit). There might be something else there that needs looking at though. -Rahul -- Wendy
Re: Shale home page
On 9/25/06, Wendy Smoak [EMAIL PROTECTED] wrote: Someone on IRC brought up a good point about the Shale home page: We don't say what Shale *is* until 1/3 of the way down the page. I think the information in the paragraph that starts Thus, Shale is... belongs up at the top of the page. Thoughts? Volunteers to fix it? :) snip/ We really need to do this. I plan to make some changes as time permits (probably next week): * Remove logo bit from home page * Move the historical out to its own page * Try to add features-* pages content to the site sections of their own modules (for example, the description in the dialog module site - thanks Craig - is much more accurate and upto date that the corresponding features page) * Point to module sites rather than features-* where feasible * Move download and documentation (which is really Javadocs) sections to their own pages * The mailing lists and issue tracking blurbs on home page can go IMO, redundant given the LHS menu contains the links (need to add ML link) And then some new content, hopefully soon. -Rahul -- Wendy
Re: Framework artifact names
I've changed the artifact names as outlined below. -Rahul On 10/13/06, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ How about ditching the library, support and plugin qualifiers? How does this look: [INFO] Shale Test Framework [INFO] Shale Core [INFO] Shale Application Controller [INFO] Shale Clay [INFO] Shale Dialog Manager [INFO] Shale Dialog Manager (Basic Implementation) [INFO] Shale Dialog Manager (SCXML Implementation) [INFO] Shale Remoting [INFO] Shale Spring Integration [INFO] Shale View Controller [INFO] Shale Tiger Extensions [INFO] Shale Tiles Integration [INFO] Shale Validator Integration
Re: svn commit: r465366 - in /shale/framework/trunk/shale-apps: shale-test-tiger/src/main/java/org/apache/shale/examples/test/tiger/ shale-test-tiger/src/main/webapp/ shale-test-view/src/main/java/org
On 10/18/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 10/18/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: rahul Date: Wed Oct 18 13:49:36 2006 New Revision: 465366 URL: http://svn.apache.org/viewvc?view=revrev=465366 Log: Adding props that should've been part of r465311 and r465318. FWIW, finally figured out what was causing this ... my enable-auto-props option had gotten commented out somewhere along the way, so my settings that should have taken care of this were getting ignored. Sorry for the extra work. snip/ No problem at all, glad you found the glitch. -Rahul Craig
Re: Shale home page
On 10/18/06, David Geary [EMAIL PROTECTED] wrote: I plan to work on the home page, but I won't get much done until I get off the road for awhile, which will be in a couple of weeks. snip/ Great, you'll probably find a short description blurb (not more than 2-3 sentences--I'll try to take in the feedback from this thread) once I'm done with the items (below). Please feel free to delete/improve/adjust it as you see fit when you get a chance. Thanks, -Rahul If not working on it, I've been thinking about the homepage lately, and it strikes me that I don't really know how to spin Shale. We have so many unrelated features that it's difficult to say Shale is The addition of JPA makes things even murkier. Are we one-stop shopping for JSF? Proving ground for JSF 2.0? I know we're a set of services, but that's a rather bland description. david 2006/10/18, Craig McClanahan [EMAIL PROTECTED]: On 10/18/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 9/25/06, Wendy Smoak [EMAIL PROTECTED] wrote: Someone on IRC brought up a good point about the Shale home page: We don't say what Shale *is* until 1/3 of the way down the page. I think the information in the paragraph that starts Thus, Shale is... belongs up at the top of the page. Thoughts? Volunteers to fix it? :) snip/ We really need to do this. I plan to make some changes as time permits (probably next week): * Remove logo bit from home page * Move the historical out to its own page * Try to add features-* pages content to the site sections of their own modules (for example, the description in the dialog module site - thanks Craig - is much more accurate and upto date that the corresponding features page) * Point to module sites rather than features-* where feasible * Move download and documentation (which is really Javadocs) sections to their own pages * The mailing lists and issue tracking blurbs on home page can go IMO, redundant given the LHS menu contains the links (need to add ML link) Thanks Rahul ... +1 on all of these. One additional note on the features sections. With the way things are now spread out into submodules, I think we'll be able to completely get rid of these by the time we're done, because the information will have been distributed onto the submodule pages already. But, we'll also want to make sure that the submodule list is up to date in every website (IIRC it is manually maintained via cut-n-paste) to reflect the new additions. As for me, I'm planning on finishing up the main page for shale-dialog, and adding the rest of the stuff from features-dialog to the shale-dialog-basic page, in the next couple of days. And then some new content, hopefully soon. -Rahul Craig -- Wendy
Re: Website questions
On 10/19/06, Craig McClanahan [EMAIL PROTECTED] wrote: I've been fleshing out the front page docs of several of the new subproject modules[1][2][3], but on the actual site these pages don't have the overall banner and logo that the front page has. Shouldn't they? snip/ There is supposed to be site.xml inheritance (to some extent). That extent is either not documented very well or I can't find it (for example, I know menu elements can be inherited, I guess there may also require a minimum version requirement of the site plugin for that etc.) If so, what do we need to configure to make that happen? snap/ Well, we could just add the banner bits to the modules' site.xml files since they probably won't change very often. -Rahul Craig [1] http://shale.apache.org/shale-dialog/index.html [2] http://shale.apache.org/shale-dialog-basic/index.html [3] http://shale.apache.org/shale-view/index.html
Re: svn commit: r465422 - in /shale/framework/trunk/shale-clay/src: main/java/org/apache/shale/clay/parser/builder/ test/java/org/apache/shale/clay/config/ test/resources/org/apache/shale/clay/config/
On 10/18/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: gvanmatre Date: Wed Oct 18 16:37:05 2006 New Revision: 465422 URL: http://svn.apache.org/viewvc?view=revrev=465422 Log: This is a fix for the Clay implicit anchored tag mapping that was not assigning the href to the component's value attribute. It was reported by Torsten Krah (SHALE-313). Added: shale/framework/trunk/shale-clay/src/test/java/org/apache/shale/clay/config/ImplicitMappingTestCase.java (with props) shale/framework/trunk/shale-clay/src/test/resources/org/apache/shale/clay/config/implicit.html (with props) snip/ Gary, can you please add ASLv2 headers to new files? Don't worry about these two -- as part of my todo list, I'm planning on adding them to any missing source files (my guess would be we're missing these in quite a few files, probably all in the test and site docs categories. I plan to drop in the headers when I get a chance since these tend to get packaged in the source distributions -- unless these are objections to doing so). -Rahul
Re: Website questions
On 10/20/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 10/20/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Unrelated question, but subject still applicable: Is the site updated manually (mvn site-deploy) or nightly? If manually, any caveats to be aware of? We're sharing the Continuum instance on the MyFaces zone, and it's configured to publish the site (individual module) when anything changes. You can also run 'mvn site site:deploy' to publish it yourself. snip/ Thanks, and I can do that in framework to update all modules? TIA, -Rahul -- Wendy
Re: svn commit: r465422 - in /shale/framework/trunk/shale-clay/src: main/java/org/apache/shale/clay/parser/builder/ test/java/org/apache/shale/clay/config/ test/resources/org/apache/shale/clay/config/
On 10/20/06, Gary VanMatre [EMAIL PROTECTED] wrote: From: Rahul Akolkar [EMAIL PROTECTED] On 10/18/06, [EMAIL PROTECTED] wrote: Author: gvanmatre Date: Wed Oct 18 16:37:05 2006 New Revision: 465422 URL: http://svn.apache.org/viewvc?view=revrev=465422 Log: This is a fix for the Clay implicit anchored tag mapping that was not assigning the href to the component's value attribute. It was reported by Torsten Krah (SHALE-313). Added: shale/framework/trunk/shale-clay/src/test/java/org/apache/shale/clay/config/Impl icitMappingTestCase.java (with props) shale/framework/trunk/shale-clay/src/test/resources/org/apache/shale/clay/config /implicit.html (with props) Gary, can you please add ASLv2 headers to new files? Don't worry about these two -- as part of my todo list, I'm planning on adding them to any missing source files (my guess would be we're missing these in quite a few files, probably all in the test and site docs categories. I plan to drop in the headers when I get a chance since these tend to get packaged in the source distributions -- unless these are objections to doing so). I did add svn:eol-style of native. What other options do we need for test cases and html resources? I figured that svn:keywords wouldn't apply to these types of resources? snip/ I was actually mentioning the missing ASF license header (that should be at the top of source files) in that comment. As far as svn props are concerned, I add keywords to (java) test cases and html resources (I think we should), but the comment above isn't about svn props. -Rahul -Rahul Gary
Re: Website questions
On 10/20/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 10/20/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 10/20/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Unrelated question, but subject still applicable: Is the site updated manually (mvn site-deploy) or nightly? If manually, any caveats to be aware of? We're sharing the Continuum instance on the MyFaces zone, and it's configured to publish the site (individual module) when anything changes. Along with that, you just need to remember publish in this context means copying it to people.apache.org. From there, it is rsync'd to the real webserver on some schedule that I can never keep in my head ... but the thing to remember is that there is not an instantaneous turnaround on changes. snip/ Yup, we do the same in Jakarta Taglibs (Glenn's machine runs the nightly 'up' for the sites, instead of continuum). -Rahul Craig You can also run 'mvn site site:deploy' to publish it yourself. -- Wendy
Re: svn commit: r465422 - in /shale/framework/trunk/shale-clay/src: main/java/org/apache/shale/clay/parser/builder/ test/java/org/apache/shale/clay/config/ test/resources/org/apache/shale/clay/config/
On 10/20/06, Gary VanMatre [EMAIL PROTECTED] wrote: From: Rahul Akolkar [EMAIL PROTECTED] snip/ I was actually mentioning the missing ASF license header (that should be at the top of source files) in that comment. As far as svn props are concerned, I add keywords to (java) test cases and html resources (I think we should), but the comment above isn't about svn props. -Rahul Cool, I'll add it to the java source but adding it to the html resource would mess with what is being tested. snap/ Thanks. On the html resources front, I'd have thought we can drop the license in a html comment between the clay:remove start and end comments at the beginning and not affect what is being tested at all? I can do that (though won't be immediate), if its OK with you and others. -Rahul -Rahul Gary
Re: Nightly distributions via Maven (including the j4 bits)
On 10/23/06, James Mitchell [EMAIL PROTECTED] wrote: Wendy or anyone who knows... I added the maven config to shale-tiger and shale-apps/shale-sql- browser a while back, but I can't seem to figure out how to have those as part of the assembly... Here's what I do now: $ cd shale/framework/ $ mvn clean install site -Papps,itest,j4 -Djava14.jar= $JAVA_HOME/../Classes/classes.jar $ cd shale-dist/ $ mvn clean assembly:assembly When I unpack the zip, there is no apps, and no j4 jars/wars (even though I see them under target of each). snip/ IIUC, for artifacts to be packed in the dist zip, they have to be either declared as deps in the shale-dist pom [1] (for publishable artifacts) or, for other resources (such as j4 jars/wars), the assembly descriptor [2] would have to pull them in (since the j4 artifacts aren't published anywhere under separate artifactIDs). -Rahul [1] http://svn.apache.org/repos/asf/shale/framework/trunk/shale-dist/pom.xml [2] http://svn.apache.org/repos/asf/shale/framework/trunk/shale-dist/src/assemble/dist.xml Help?!?!? -- James Mitchell 678.910.8017
Re: calling authors
Replying to the most relevant list ... On 10/25/06, Kito D. Mann [EMAIL PROTECTED] wrote: Hello, I'm currently looking for people who are interested in writing great articles for JSF Central about MyFaces, Tomahawk, Tobago, Trinidad, or Shale. If you're interested, please reply! snip/ I'd like to write about a couple of things Shale, but have a full plate ATM. Is there an expiration date on that offer? ;-) -Rahul ~~~ Kito D. Mann ([EMAIL PROTECTED]) Author, JavaServer Faces in Action http://www.virtua.com http://www.virtua.com/ - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com http://www.jsfcentral.com/ - JavaServer Faces FAQ, news, and info
Re: Release of 1.0.4 ?
On 10/26/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi Guys, I know the main focus, or one of the main points of a 1.0.4 was the dialog manager. I saw that Craig/Raul were active on that. Is there any timeframe when you guys like to go with a new release ? snip/ I need a week to wrap up some things (majority is dialog documentation for SCXML impl and some TODOs in code). I'll also tinker with the one pending issue of browser buttons and history, lets see if anything comes out of that. If no one else has a higher upper bound on their estimates, we can get cranking on 1.0.4 late next week. Other than the significant improvement in the dialogs API, we've also had JSF 1.2 support for shale-test and numerous Clay additions post 1.0.3 as well (such as the encoding bits, clay:remove etc.). I've made a bunch of changes to the site, it'll get updated whenever continuum is happy again. We do need to get some of the site documentation ready for the release, however. For instance, post SHALE-299 and SHALE-300 (the core re-org bits), the using page [1] is considerably out of sync with trunk. -Rahul [1] http://shale.apache.org/using.html or a RC ? Thanks, Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: CommonsValidator logging
On 10/29/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 10/27/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 10/26/06, Rahul Akolkar [EMAIL PROTECTED] wrote: We have a jul Logger and a JCL log in oasv.CommonsValidator We're still using JCL elsewhere, so unless there is an all-encompassing change, I'd recommend we lose the jul Logger. Objections? snip/ Switched to JCL before I forget this. +1 for now ... but there's an outstanding ticket to switch all of Shale to j.u.l at some point that we should talk about sometime on the dev list. snip/ Thats a good option IMO for 1.4+ projects, but given that we've a number of deps that use JCL it may buy us little ATM, and possibly complicate the logging configuration. As a concrete example, if we remove the JCL dep from shale-dialog-scxml, there still is that runtime dep due to Commons SCXML. We can go one step ahead and take care of it in Commons SCXML (I had given it some thought prior to v0.5), but we're in turn bound by Commons Digester. So. I think it is generally accepted that any current web application framework will end up having JCL on classpath, one way or the other. -Rahul -Rahul Craig -Rahul
Site perms
Getting failures for cobertura directories in modules (for example: shale-core). Probably need Sean (schof) to g+w them, whenever he sees this. -Rahul
Re: Site perms
On 11/7/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 11/7/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Getting failures for cobertura directories in modules (for example: shale-core). Probably need Sean (schof) to g+w them, whenever he sees this. Sean owns them because it's his key that Continuum is using. I'll check in my fix permissions script and schedule it to run nightly. snip/ I see. TIA for the fix permissions runs. We could have Continuum run the Shale nightly builds as well. If someone would like to take a stab at a new script, you can work from Craig's current script: http://svn.apache.org/repos/asf/shale/maven/trunk/etc/buildShaleNightlyMaven.sh snap/ I may have missed it, what needs to be done here? -Rahul And the one MyFaces uses: http://svn.apache.org/repos/asf/myfaces/maven/trunk/build-world.sh -- Wendy
Re: Building source, missing Tiles snapshot stuff?
On 11/8/06, Craig McClanahan [EMAIL PROTECTED] wrote: I'm setting up a clean build environment to get rid of some wierd ghosts in my environment, and just checked out a fresh set of Shale sources (and a clean Maven2 repository). When I get to the shale-tiles build, I get the following error: Project ID: null:tiles-core:jar:2.0-r468346-SNAPSHOT Reason: Cannot find parent: org.apache.struts.tiles:tiles-parent for project: null:tiles-core:jar:2.0-r468346-SNAPSHOT Did the date-stamped parent POM get deployed to the snapshot repository? snip/ Yes, its here [1]. Indeed, m2 grabs the timestamped snap for me [2] (parent pom and all). The null groupId you're seeing is odd. -Rahul [1] http://people.apache.org/repo/m2-snapshot-repository/org/apache/struts/tiles/tiles-core/2.0-r468346-SNAPSHOT/ [2] (relevant bits from the build output) [INFO] [INFO] Building Shale Tiles Integration [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] snapshot org.apache.struts.tiles:tiles-core:2.0-r468346-SNAPSHOT: checking for updates from apache.snapshots Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/struts/tiles/tiles-core/2.0-r468346-SNAPSHOT/tiles-core-2.0-r468346-SNAPSHOT.pom 3K downloaded [INFO] snapshot org.apache.struts.tiles:tiles-parent:2.0-r468346-SNAPSHOT: checking for updates from apache.snapshots Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/struts/tiles/tiles-parent/2.0-r468346-SNAPSHOT/tiles-parent-2.0-r468346-SNAPSHOT.pom 6K downloaded Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/struts/tiles/tiles-core/2.0-r468346-SNAPSHOT/tiles-core-2.0-r468346-SNAPSHOT.jar 129K downloaded [INFO] [compiler:compile] Craig
Re: Cleaning up remaining Shale JIRA issues
On 11/10/06, Craig McClanahan [EMAIL PROTECTED] wrote: snip/ SHALE-230 -- Restore publishing the dialog_1.0.dtd file (and any other DTDs defined by Shale) snap/ Note to self: Drop in a DTD for the dialog-config in SCXML dialogs for a validating digester. Up For Grabs: SHALE-286 -- Shale+jsf+tiles can not work SHALE-288 -- Prerender does not get invoked in a portlet SHALE-302 -- TilesViewHandler does not work for JSF 1.2 SHALE-303 -- minlength and maxlength validators not working SHALE-317 -- Annotations do not work in Jetty SHALE-320 -- Catch-all for bugs identified by static code analysis tools SHALE-323 -- Wrong output directoryname in shale-archetype-blank pom Of course, anyone who wants to can go after the Up For Grabs list. :-) snip/ Claimed 306 [1] and 320 [2]. Both are mostly done for now, will take another look in the latter half of next week. -Rahul [1] https://issues.apache.org/struts/browse/SHALE-306 [2] https://issues.apache.org/struts/browse/SHALE-320 Thanks, Craig
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/11/06, Rahul Akolkar [EMAIL PROTECTED] wrote: 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: * We needed a servlet context listener that can call PropertyUtils.clearDescriptors() and LogFactory.release(). * In order to get this without requiring the user to configure a listener manually in web.xml, create a dummy tag library inside the JAR (META-INF/taglib.tld) that serves to declare the listener. * Since we now have an application startup/shutdown instance, migrate the dialog configuration parsing from first use in BasicDialogManager to application startup time as well. With these changes, we have successfully cleaned up issues that caused the Commons BeanUtils and Commons Logging jars to remain locked after undeployment on a Windows platform. However, there is still something that prevents shale-dialog-basic-xxx.jar itself from being deleted -- and this means there will be a memory leak over multiple application deploys and undeploys. This needs to be investigated and fixed before this issue can be considered as dealt with for the basic implementation. The Commons SCXML implementation is going to need the same sort of changes (can be tagged against SHALE-274 as well), but it's likely to have its own set of different issues about leaving the shale-dialog-scxml-xxx.jar file locked. snip/ Thanks for the heads-up. Will take a look at the Commons SCXML impl from a similar perspective when I'm done traveling (Wed). snip/ OK, can't seem to reproduce this locally (even without the JCL and BeanUtils cleanup, since the dialog-scxml module doesn't yet have that). I'm on: XP SP2 Tomcat 5.0.28 (using manager to undeploy) Any other hints? -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/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: snip/ 6.0.1 -- Cannot use the manager app at all because the tomcat-users.xml file gets wiped out (I filed a Tomcat bug on this one). Also get JSP errors when trying to run the app manually ... this is likely due to either more Tomcat bugs, or to something we're not declaring right in a Servlet 2.5 / JSP 2.1environment. snap/ Yeah, I saw your bug report and decided to spare myself the teething trouble. -Rahul Craig
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
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: 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: 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: [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: 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: 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: 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: 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: 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
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 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
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: [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
[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: [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
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: [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: [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
[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] 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
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
