Re: File upload
On 7/24/07, Hetal Varma <[EMAIL PROTECTED]> wrote: Hi, I want a code for uploading a file to the location (that should be user specific means user select at runtime- on the server). This list is for development discussions related to Commons components. Please try the user list instead for usage questions. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] dbcp failed.
On 7/24/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: Can anyone else reproduce this failure? Yes (XP, Tiger, m102). -Rahul -dain On Jul 24, 2007, at 3:03 AM, Phil Steitz wrote: > Failed build logs: > http://vmbuild.apache.org/~commons/nightly/logs//20070724/dbcp.log > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Remove SQLNestedException
On 7/24/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: On Jul 24, 2007, at 7:56 AM, Phil Steitz wrote: > On 7/23/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: >> >> So, should we drop SQLNestedException? > > This is tempting, but it breaks backward compatibility, so we should > probably deprecate in 1.3 and remove in the next major release. I > guess the deprecation warning / release notes should just tell people > to remove "legacy" casts in client code, since we never advertise this > exception. Sounds good. I marked the class as deprecated, moved DBCP-143 to 1.4, and added a note to the change log. He means v2.0 AFAICT. Details [1]. -Rahul [1] http://jakarta.apache.org/commons/releases/versioning.html -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dbcp] svn props (was: svn commit: r558884)
On 7/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: dain Date: Mon Jul 23 15:28:37 2007 New Revision: 558884 URL: http://svn.apache.org/viewvc?view=rev&rev=558884 Log: DBCP-221 Changed BasicDataSource.close() to permanently mark the data source as closed. At close all idle connections are destroyed and the method returns. As existing active connections are closed, they are destroyed. Added: jakarta/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/managed/TestBasicManagedDataSource.java It seems no props were added. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DIGESTER-115) Digester depends on BeanUtils copies of Collections classes
[ https://issues.apache.org/jira/browse/DIGESTER-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513979 ] Rahul Akolkar commented on DIGESTER-115: But a "tighter" ArrayStack wouldn't work (given fix version is 1.8.1). In the longer run, I agree, we should wean [digester] off of the [collections] version of ArrayStack (doing what you suggest or just using java.util.Stack or some such so we will have one less class to maintain). > Digester depends on BeanUtils copies of Collections classes > --- > > Key: DIGESTER-115 > URL: https://issues.apache.org/jira/browse/DIGESTER-115 > Project: Commons Digester > Issue Type: Bug >Affects Versions: 1.8 >Reporter: Niall Pemberton > Fix For: 1.8.1 > > > This is related to issue# BEANUTILS-278 > Digester uses 3 classes (ArrayStack, Buffer and BufferUnderflowException) > from commons BeanUtils which were copied from Commons Collections and > BEANUTILS-278 proposes removing them. > ArrayStack.java > Buffer.java > BufferUnderflowException.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r556299 - /jakarta/commons/trunks-proper/
Author: rahul Date: Sat Jul 14 10:23:59 2007 New Revision: 556299 URL: http://svn.apache.org/viewvc?view=rev&rev=556299 Log: Remove httpclient from externals. Modified: jakarta/commons/trunks-proper/ (props changed) Propchange: jakarta/commons/trunks-proper/ -- --- svn:externals (original) +++ svn:externals Sat Jul 14 10:23:59 2007 @@ -19,7 +19,6 @@ el https://svn.apache.org/repos/asf/jakarta/commons/proper/el/trunk email https://svn.apache.org/repos/asf/jakarta/commons/proper/email/trunk fileupload https://svn.apache.org/repos/asf/jakarta/commons/proper/fileupload/trunk -httpclient https://svn.apache.org/repos/asf/jakarta/commons/proper/httpclient/trunk io https://svn.apache.org/repos/asf/jakarta/commons/proper/io/trunk jci https://svn.apache.org/repos/asf/jakarta/commons/proper/jci/trunk jelly https://svn.apache.org/repos/asf/jakarta/commons/proper/jelly/trunk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Commons Board Report, July 2007
I think your email client may be messing with the formatting. See paste below (I don't know if it appears that way to others as well). I'm getting lines broken and misaligned -- as a result links fragmented as well -- its harder to read than it should be :-) -Rahul Community = o We agreed to only migrate commit rights of committers that did a commit in the past 2 years. Of course any previous committer just has to ask to get his rights back at any time. See the jira issue for the initial list of committers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [BeanUtils] Progressing towards a 1.8.0 release
On 7/12/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: BeanUtils is getting close to being ready for a 1.8.0 release IMO (under 10 issues left targeted for 1.8.0). http://issues.apache.org/jira/browse/BEANUTILS Thanks for all the work! One thought I had was to do a 1.8.0 Beta release first to (hopefully) get wider testing - thoughts/opinions on that welcome. IMO, a 1.8.0 Beta sounds like a good idea since there are a few changes and much downstream testing can be done -- it will give folks some more time to react. For example, I intend to run the gamut of tests (Digester -> SCXML -> things SCXML depends on) and having a Beta release would let me do that in a more relaxed fashion. -Rahul Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [httpclient] Remove from trunks-proper? (was: svn commit: r553886)
If there are no objections (say within three days), I will remove httpclient from the externals on trunks-proper as well. -Rahul On 7/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: rolandw Date: Fri Jul 6 07:12:06 2007 New Revision: 553886 URL: http://svn.apache.org/viewvc?view=rev&rev=553886 Log: HttpClient trunk has moved to http://svn.apache.org/repos/asf/jakarta/httpcomponents/oac.hc3x/trunk/ Removed: jakarta/commons/proper/httpclient/trunk/docs/ jakarta/commons/proper/httpclient/trunk/src/ jakarta/commons/proper/httpclient/trunk/xdocs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SCXML-49) SimpleSCXMLInvoker may miss transition to final state
[ https://issues.apache.org/jira/browse/SCXML-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Akolkar updated SCXML-49: --- Fix Version/s: 0.7 Assignee: Rahul Akolkar Affects Version/s: (was: 0.7) 0.6 Setting fix version to next release. > SimpleSCXMLInvoker may miss transition to final state > - > > Key: SCXML-49 > URL: https://issues.apache.org/jira/browse/SCXML-49 > Project: Commons SCXML > Issue Type: Bug >Affects Versions: 0.6 >Reporter: Ingmar Kliche >Assignee: Rahul Akolkar > Fix For: 0.7 > > > The current implementation of SimpleSCXMLInvoker assumes that only external > events, handled by parentEvents(), may cause the child state machine to go > move a final state. But in case where the invoked state machine moves to a > final state directly (while executing the initial state, see example) the > parent never receives an "invoke.done". > > http://www.w3.org/2005/07/scxml version="1.0" > initialstate="state1"> > > > > > > > > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: board report
On 7/8/07, Torsten Curdt <[EMAIL PROTECTED]> wrote: I need to prepare the first Commons board report. So far I came up with: Releases o 02 July Commons IO 1.3.2 Infrastructure o Still work to be done for TLP https://issues.apache.org/jira/ browse/INFRA-1283 Community o We agreed to only migrate commit rights of committers that did a commit in the past 2 years. Of course any previous committer just has to ask to get his rights back at any time. See the jira issue for the initial list of committers o No new committers o No new PMC members Technically, we have two new PMC members (Simon and me). -Rahul Anything else we should add? cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] No VOTE needed to elect ASF committers to commons WAS: Re: request karma to commons validator/i18n
On 7/8/07, Henri Yandell <[EMAIL PROTECTED]> wrote: On 7/6/07, Phil Steitz <[EMAIL PROTECTED]> wrote: > So my proposal is that any ASF committer who wishes to become a > commons committer just needs to make that request here on the > commons-dev mailing list and they will granted karma for both commons > proper and commons sandbox. Expectation is of course that ASF > committers joining the commons will "behave" > (http://wiki.apache.org/jakarta-commons/JakartaCommonsEtiquette). Obviously I'm +1 on making it easier. I will try to dispel this particular "making it easier" and "openness" myth :-) * I don't think its hard in the first place (unless someone doesn't care to try, but then they probably don't care enough anyway). * There is a difference between sandbox and proper. Sandbox is open to all ASF committers with the intent that new ideas should be allowed to flourish at minimal starter costs. * Released components can (potentially, hah!) have direction and roadmaps. Its not the same as sandbox. * My personal opinion after our similar experiment at Jakarta is that this sort of thing is good to flaunt in theory. * Finally, I'm not saying we need to get existing ASF committers to supply n number of patches before we can nominate them etc. All I'm saying is IMO this is important enough for the health of the community to be done on a case by case basis. As far as behaving - the solution is that the quiet majority have to step up and yell if someone is being a rude . Somewhat late, much damage is done. Ofcourse, its not possible to guarantee this will never happen as we operate today, but IMO the chances are smaller. We've a bit of a technical issue on it; it's quite easy to show up and if a component is in a lull, to charge in and make sweeping changes. The release is a point where we can nip that in the bud, but that's a long time after lots of work. Yup. So I think something I would be looking for when someone wants to hop in is that there is an active commons committer managing the component they're about to commit to. Agreed, note the current modus operandi sort of helps with that too. Other than that, I believe in as open a door as possible. Me too, as long as there is a door :-) -Rahul Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release CLI 1.1 (3rd RC)
On 7/4/07, Henri Yandell <[EMAIL PROTECTED]> wrote: [X] +1, before 6 years since 1.0 arrives [ ] -1, we can make 6 years --- The only changes to svn are Rahul's NOTICE fix for our TLP change and Sorry about that. -Rahul my updating the RELEASE-NOTES.txt with the latest information. So I plan to consider any existing +1s for the RC2 as applying to this (ie: Don't revote unless you want to). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCXML] SimpleSCXMLInvoker may miss transition to final state
On 7/6/07, Ingmar Kliche <[EMAIL PROTECTED]> wrote:
The current implementation of SimpleSCXMLInvoker assumes that only external
events, handled by parentEvents(), may cause the child state machine to
go move a final state. I had a case where the invoked state machine went to
a final state directly while executing the initial state, something like:
http://www.w3.org/2005/07/scxml version="1.0"
initialstate="state1">
Therefore the invoke got stucked and the parent never received an
invoke.done event.
Yes, this looks like a problem. Again, please file tickets in JIRA [1]
-- if you can attach simple testcases that'd be very helpful.
I see two problems:
a) the parentEvents() method will not send a "invoke.done" event to the
parent because "doneBefore" will already be true (for the above example).
That means the parent gets never notified about the termination of the
child.
b) Even if we change the logic of parentEvents() in a way that a) will be
solved, the problem is still that the termination of the state machine will
only be detected once an external event occurs in the parent state machine
and thus the parentEvents() method will be called.
Is there a way to get notified in the environment of a state machine (like
the invoke-Implementation) once a state machine reaches the final state?
Until now I only found "polling" the current state like
if (executor.getCurrentStatus().isFinal()) { ..}
Don't we need a callback (implemented by an interface) to get notified about
reaching a final state? The child state machine (invoked from a parent state
machine) may communicate to another external process asynchronously and any
event from this external process may cause the child state machine to go to
a final state. How to notify the parent about termination of the invoke (i.e.
sending an invoke.done)?
Correct, the canonical way is to poll. However, it is possible to
register a SCXMLListener and that gives us callbacks (at the least,
these tell us when to poll :-). The SimpleSCXMLInvoker is so called
because I think its possible to write a NotSoSimpleSCXMLInvoker that
does things like these better. Since Invoker registration is upto the
user, the idea was that the simple one would provide a skeleton to get
folks started.
-Rahul
[1] http://jakarta.apache.org/commons/scxml/issue-tracking.html
- Ingmar.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] No VOTE needed to elect ASF committers to commons WAS: Re: request karma to commons validator/i18n
On 7/6/07, Phil Steitz <[EMAIL PROTECTED]> wrote: On 7/6/07, Henri Yandell <[EMAIL PROTECTED]> wrote: > On 7/6/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > > > Although Commons has a liberal policy on giving Karma to ASF > > committers a better (more ASF like) first step IMO would have been to > > start talking about what you want to do first - a good recent example > > of that is Dain: > > > > http://tinyurl.com/yrmgpf > > > > Even though I'm already a committer I still regularly create Jira > > tickets and post patches (for code changes) to components that I don't > > have much history on rather than diving straight in. I'm hoping > > you'll do the same, 'coz I'm going to be unhappy if I start seeing > > Validator commits with no prior discussion. > > Ack - Martin just pointed out that it's Sandbox karma on request, not > all of Commons. > > I'll adjust - ie: Paul will have commit for i18n, but we'll have to > vote to give him commit to validator. > Sorry, I thought we had changed that policy, so I guess I would like to propose that we change it now. It does not really make sense to me to distinguish the sandbox and I think we should make it as easy as possible for existing ASF committers to contribute to commons. So my proposal is that any ASF committer who wishes to become a commons committer just needs to make that request here on the commons-dev mailing list and they will granted karma for both commons proper and commons sandbox. Expectation is of course that ASF committers joining the commons will "behave" (http://wiki.apache.org/jakarta-commons/JakartaCommonsEtiquette). I hope ASF committers learn nothing new on the etiquette front (there may indeed be some procedural novelties) after reading that document :-) But since I can't personally vouch for all, I don't care much for this proposal. As an alternative, we could discuss requests for karma from ASF committers on private@ (good sign that we have not even created that yet :) but I don't personally see the need to do that. In any case, I don't think we should revert to the old practice of public committer votes (whether or not the individual is a current ASF committer). Sure, that makes sense. -Rahul Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCXML] Inject external event with XML payload () into SCXML engine
Please post to the user list if the question is purely about usage (though I understand determining that can be tricky sometimes). If this thread continues, we should probably move it to the user list. On 7/5/07, Ingmar Kliche <[EMAIL PROTECTED]> wrote: Rahul, I would like to inject events with XML payload into the SCXML engine. Currently we have to convert XML represented messages received from external components into a hashmap object to fire the event into the engine. But this does not allow to include XML attributes easily. Suppose we have an event which is represented as an EMMA string, e.g. (borrowed from [1]) Boston Denver Austin Denver How do we pass this into the SCXML engine? My goal is to pass this XML data into the SCXML data model and operate on the event data using XPath. Do you have any suggestion? Might be best to parse the EMMA into its DOM before attaching it to the payload (say under property 'emma'). Then you can get to it like so: Data( _eventdata.emma , '/some/xpath' ) You can define expression language functions to do more specialized things. You can use to store the payload in the SCXML data model. -Rahul - Ingmar. [1] http://www.w3.org/TR/emma - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r553294 - in /jakarta/commons/proper: attributes/trunk/ beanutils/trunk/ betwixt/trunk/ chain/trunk/ cli/branches/cli-1.0.x/ cli/trunk/ codec/trunk/ collections/trunk/ commons-parent/trunk
Author: rahul Date: Wed Jul 4 11:26:27 2007 New Revision: 553294 URL: http://svn.apache.org/viewvc?view=rev&rev=553294 Log: Update NOTICE files in trunks-proper in light of TLP move (and add component names to NOTICEs where missing). Modified: jakarta/commons/proper/attributes/trunk/NOTICE.txt jakarta/commons/proper/beanutils/trunk/NOTICE.txt jakarta/commons/proper/betwixt/trunk/NOTICE.txt jakarta/commons/proper/chain/trunk/NOTICE.txt jakarta/commons/proper/cli/branches/cli-1.0.x/NOTICE.txt jakarta/commons/proper/cli/trunk/NOTICE.txt jakarta/commons/proper/codec/trunk/NOTICE.txt jakarta/commons/proper/collections/trunk/NOTICE.txt jakarta/commons/proper/commons-parent/trunk/NOTICE.txt jakarta/commons/proper/commons-sandbox-parent/trunk/NOTICE.txt jakarta/commons/proper/configuration/trunk/NOTICE.txt jakarta/commons/proper/daemon/trunk/NOTICE.txt jakarta/commons/proper/dbcp/trunk/NOTICE.txt jakarta/commons/proper/dbutils/trunk/NOTICE.txt jakarta/commons/proper/digester/trunk/NOTICE.txt jakarta/commons/proper/discovery/trunk/NOTICE.txt jakarta/commons/proper/el/trunk/NOTICE.txt jakarta/commons/proper/email/trunk/NOTICE.txt jakarta/commons/proper/fileupload/trunk/NOTICE.txt jakarta/commons/proper/io/trunk/NOTICE.txt jakarta/commons/proper/jci/trunk/NOTICE.txt jakarta/commons/proper/jelly/trunk/NOTICE.txt jakarta/commons/proper/jexl/trunk/NOTICE.txt jakarta/commons/proper/jxpath/trunk/NOTICE.txt jakarta/commons/proper/lang/trunk/NOTICE.txt jakarta/commons/proper/launcher/trunk/NOTICE.txt jakarta/commons/proper/logging/trunk/NOTICE.txt jakarta/commons/proper/math/trunk/NOTICE.txt jakarta/commons/proper/modeler/trunk/NOTICE.txt jakarta/commons/proper/net/trunk/NOTICE.txt jakarta/commons/proper/pool/trunk/NOTICE.txt jakarta/commons/proper/primitives/trunk/NOTICE.txt jakarta/commons/proper/scxml/trunk/NOTICE.txt jakarta/commons/proper/transaction/trunk/NOTICE.txt jakarta/commons/proper/validator/trunk/NOTICE.txt jakarta/commons/proper/vfs/trunk/NOTICE.txt Modified: jakarta/commons/proper/attributes/trunk/NOTICE.txt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/attributes/trunk/NOTICE.txt?view=diff&rev=553294&r1=553293&r2=553294 == --- jakarta/commons/proper/attributes/trunk/NOTICE.txt (original) +++ jakarta/commons/proper/attributes/trunk/NOTICE.txt Wed Jul 4 11:26:27 2007 @@ -1,4 +1,4 @@ -Apache Jakarta Commons Attributes +Apache Commons Attributes Copyright 2003-2006 The Apache Software Foundation This product includes software developed by Modified: jakarta/commons/proper/beanutils/trunk/NOTICE.txt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/NOTICE.txt?view=diff&rev=553294&r1=553293&r2=553294 == --- jakarta/commons/proper/beanutils/trunk/NOTICE.txt (original) +++ jakarta/commons/proper/beanutils/trunk/NOTICE.txt Wed Jul 4 11:26:27 2007 @@ -1,4 +1,4 @@ -Apache Jakarta Commons BeanUtils +Apache Commons BeanUtils Copyright 2001-2006 The Apache Software Foundation This product includes software developed by Modified: jakarta/commons/proper/betwixt/trunk/NOTICE.txt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/betwixt/trunk/NOTICE.txt?view=diff&rev=553294&r1=553293&r2=553294 == --- jakarta/commons/proper/betwixt/trunk/NOTICE.txt (original) +++ jakarta/commons/proper/betwixt/trunk/NOTICE.txt Wed Jul 4 11:26:27 2007 @@ -1,4 +1,4 @@ -Apache Jakarta Commons Betwixt +Apache Commons Betwixt Copyright 2001-2006 The Apache Software Foundation This product includes software developed by Modified: jakarta/commons/proper/chain/trunk/NOTICE.txt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/chain/trunk/NOTICE.txt?view=diff&rev=553294&r1=553293&r2=553294 == --- jakarta/commons/proper/chain/trunk/NOTICE.txt (original) +++ jakarta/commons/proper/chain/trunk/NOTICE.txt Wed Jul 4 11:26:27 2007 @@ -1,4 +1,4 @@ -Apache Jakarta Commons Chain +Apache Commons Chain Copyright 2001-2006 The Apache Software Foundation This product includes software developed by Modified: jakarta/commons/proper/cli/branches/cli-1.0.x/NOTICE.txt URL: http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/cli-1.0.x/NOTICE.txt?view=diff&rev=553294&r1=553293&r2=553294 == --- jakarta/commons/proper/cli/branches/cli-1.0.x/NOTICE.txt (original) +++ jakarta/commons/proper/cli/branches/cli-1.0.x/NOTICE.txt Wed Jul 4 11:26:27 2007 @@ -1,4 +1,4 @@ -Apache Jakarta Commons CLI +Apache
Re: moderators for [EMAIL PROTECTED]
On 7/3/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: On Mon, 2007-07-02 at 15:13 -0400, Rahul Akolkar wrote: > On 7/2/07, Matt Benson <[EMAIL PROTECTED]> wrote: > > How arduous a task is it? > > > > > Most I've spent is ~5 minutes in one day. "Requirement" would be > people who generally check email atleast once a day. one of my JAMES TODOs is to create a collaborative email moderation application with web interface but since i haven't even finished fixing the IMAP implementation yet, it seems a long way off... I suspect that would reach a similar level of popularity here as RAT has :-) -Rahul - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue for TLP move
On 7/3/07, Torsten Curdt <[EMAIL PROTECTED]> wrote: Hope I captured all the input. So if no one objects I will submit the following issue to infrastructure cheers -- Torsten (ii) remote moderators ... I. [EMAIL PROTECTED] moderators are [EMAIL PROTECTED] DOT org Could you please subscribe me using my gmail address (the one this message is sent from) to the private list and also use my gmail address as the moderator? The latter is the more important one -- its much more tedious to use the apache address (I basically forward that to gmail anyway, and need to do a lot more mangling of the reply-to's etc. for that to work well). Thanks. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io] Tag names (was: svn commit: r552581)
On 7/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: jochen Date: Mon Jul 2 13:21:44 2007 New Revision: 552581 URL: http://svn.apache.org/viewvc?view=rev&rev=552581 Log: (empty) Added: jakarta/commons/proper/io/tags/commons-io-1.3.2/ - copied from r552580, jakarta/commons/proper/io/branches/b1_3/ Please use consistent names for release tags. This is a misfit: http://svn.apache.org/repos/asf/jakarta/commons/proper/io/tags/ It would be even better, IMO, if you tag RCs and copy the appropriate one as the release tag. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: moderators for [EMAIL PROTECTED]
On 7/2/07, Matt Benson <[EMAIL PROTECTED]> wrote: How arduous a task is it? Most I've spent is ~5 minutes in one day. "Requirement" would be people who generally check email atleast once a day. -Rahul -Matt --- Torsten Curdt <[EMAIL PROTECTED]> wrote: > Anyone willing to do it? > > cheers > -- > Torsten > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: moderators for [EMAIL PROTECTED]
On 7/2/07, Torsten Curdt <[EMAIL PROTECTED]> wrote: Anyone willing to do it? I'm moderating a couple at Jakarta, and can do this one too. It'd be good to have more than one moderator. -Rahul cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 4th attempt: Release commons-io 1.3.2
+1 We should change all NOTICEs to say Apache Commons * (without Jakarta). I'll do that, sometime this week. -Rahul On 6/26/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: Hi, I have prepared a further release candidate, with the following changes: - Deprecation tags have been removed from the FileCleaner. (In the 1.3 branch only, not in the trunk.) The discussion has clearly shown, that opinions vary on this topic, nevertheless I feel forced to make that change against my personal opinion. IMO, releasing a 1.4 release with as little changes as that would be the greater evil. - The extracted source distribution is now using the -src suffix. - The .md5 and .sha1 files meet the commons standard and have the format * Please cast your vote. Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SCXML-47) Provide a state machine support class to allow for delegation.
[
https://issues.apache.org/jira/browse/SCXML-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508326
]
Rahul Akolkar commented on SCXML-47:
Indeed, that should be out of the way. Please ping if it isn't. While I was at
it, I've added the additional constructors that avoid the recurring parsing
cost (by accepting the parsed SCXML instance instead of the URL to the
document).
> Provide a state machine support class to allow for delegation.
> --
>
> Key: SCXML-47
> URL: https://issues.apache.org/jira/browse/SCXML-47
> Project: Commons SCXML
> Issue Type: Improvement
>Affects Versions: 0.6
>Reporter: Michael Heuer
>Priority: Minor
> Fix For: 0.7
>
> Attachments: additional-tests.tar.gz, state-machine-support-src.tar.gz
>
>
> This is not completely thought out yet, but if folks like the idea I might
> persue it further.
> I would like to use AbstractStateMachine but cannot extend from it:
> class B extends A /*, AbstractStateMachine */ {
> // copy source from AbstractStateMachine here
> }
> I propose here a StateMachineSupport class that provides for use by
> subclassing and for use by delegation. The constructors are a little messy,
> but in the end I have
> public class StateMachineSupport {
> // use by subclassing
> protected StateMachineSupport(...) {
> }
> // use by delegation
> public StateMachineSupport(Object delegator, ...) {
> }
> // ... methods from AbstractStateMachine
> }
> public abstract class AbstractStateMachine extends StateMachineSupport {
> protected AbstractStateMachine(...) {
> super(...);
> }
> }
> // use by subclassing
> class ConcreteStateMachine extends AbstractStateMachine {
> ConcreteStateMachine() {
> super(..."stopwatch.xml");
> }
> public void reset() { ... }
> public void running() { ... }
> public void paused() { ... }
> public void stopped() { ... }
> }
> // use by delegation
> class DelegatingStateMachine extends SomethingElse {
> StateMachineSupport delegate;
> DelegatingStateMachine() {
> delegate = new StateMachineSupport(this, ..."stopwatch.xml");
> }
> public void reset() { ... }
> public void running() { ... }
> public void paused() { ... }
> public void stopped() { ... }
> }
> StateMachineSupport.java, AbstractStateMachine2.java,
> StateMachineSupportTest.java, and AbstractStateMachine2Test.java attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (SCXML-48) Cannot create more than one subclass of AbstractStateMachine
[
https://issues.apache.org/jira/browse/SCXML-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rahul Akolkar resolved SCXML-48.
Resolution: Fixed
Fix Version/s: 0.7
Thanks for the tests. They've been added to the test suite and a fix has been
applied. Should be available in tomorrow's nightly (or immediately via trunk).
> Cannot create more than one subclass of AbstractStateMachine
>
>
> Key: SCXML-48
> URL: https://issues.apache.org/jira/browse/SCXML-48
> Project: Commons SCXML
> Issue Type: Bug
>Reporter: Michael Heuer
> Fix For: 0.7
>
> Attachments: abstract-state-machine-test-src.tar.gz
>
>
> Similar to the issue described in SCXML-47, the following test case will fail:
> public void testMoreThanOneScxmlDocument() throws Exception {
> URL fooScxmlDocument = getClass().getResource("foo.xml");
> URL barScxmlDocument = getClass().getResource("bar.xml");
> Foo foo = new Foo(fooScxmlDocument);
> Bar bar = new Bar(barScxmlDocument);
> assertTrue(fooCalled);
> // bar's initialstate "bar" never called, since bar's
> AbstractStateMachine has
> // static reference to stateMachine for foo.xml
> assertTrue(barCalled);
> }
> private class Foo extends AbstractStateMachine {
> public Foo(final URL scxmlDocument) {
> super(scxmlDocument);
> }
> public void foo() {
> fooCalled = true;
> }
> }
> private class Bar extends AbstractStateMachine {
> public Bar(final URL scxmlDocument) {
> super(scxmlDocument);
> }
> public void bar() {
> barCalled = true;
> }
> }
> with simple SCXML files
> foo.xml:
> http://www.w3.org/2005/07/scxml"; version="1.0"
> initialstate="foo">
>
>
> bar.xml:
> http://www.w3.org/2005/07/scxml"; version="1.0"
> initialstate="bar">
>
>
> [junit] Running org.apache.commons.scxml.env.EnvTestSuite
> org.apache.commons.scxml.env.AbstractStateMachineTest$Bar.foo()
> java.lang.NoSuchMethodException:
> org.apache.commons.scxml.env.AbstractStateMachineTest$Bar.foo()
> at java.lang.Class.getDeclaredMethod(Class.java:1937)
> at
> org.apache.commons.scxml.env.AbstractStateMachine.invoke(AbstractStateMachine.java:212)
> at
> org.apache.commons.scxml.env.AbstractStateMachine$EntryListener.onEntry(AbstractStateMachine.java:269)
> Testsuite: org.apache.commons.scxml.env.EnvTestSuite
> Tests run: 21, Failures: 2, Errors: 0, Time elapsed: 0.391 sec
> Testcase:
> testMoreThanOneScxmlDocument(org.apache.commons.scxml.env.AbstractStateMachineTest):
> FAILED
> junit.framework.AssertionFailedError
> at
> org.apache.commons.scxml.env.AbstractStateMachineTest.testMoreThanOneScxmlDocument(AbstractStateMachineTest.java:60)
> Testcase: testStopWatch(org.apache.commons.scxml.env.StopWatchTest):FAILED
> expected: but was:
> junit.framework.ComparisonFailure: expected: but was:
> at
> org.apache.commons.scxml.env.StopWatchTest.testStopWatch(StopWatchTest.java:56)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r550948 - in /jakarta/commons/proper/scxml/trunk/src: main/java/org/apache/commons/scxml/env/ test/java/org/apache/commons/scxml/env/
Author: rahul
Date: Tue Jun 26 13:58:10 2007
New Revision: 550948
URL: http://svn.apache.org/viewvc?view=rev&rev=550948
Log:
SCXML-48 Broken subclassing for AbstractStateMachine.
Unrelated changes:
- Two new constructors to avoid recurring parsing cost
- Some cosmetic changes so the class Javadoc renders in a readable manner.
Thanks to Michael Heuer for the AbstractStateMachine
tests (which now pass).
Added:
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/AbstractStateMachineTest.java
(with props)
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/bar.xml
(with props)
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/foo.xml
(with props)
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/AbstractStateMachine.java
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/EnvTestSuite.java
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/AbstractStateMachine.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/AbstractStateMachine.java?view=diff&rev=550948&r1=550947&r2=550948
==
---
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/AbstractStateMachine.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/AbstractStateMachine.java
Tue Jun 26 13:58:10 2007
@@ -39,27 +39,27 @@
import org.xml.sax.SAXException;
/**
- * This class demonstrates one approach for providing the base
+ * This class demonstrates one approach for providing the base
* functionality needed by classes representing stateful entities,
- * whose behaviors are defined via SCXML documents.
+ * whose behaviors are defined via SCXML documents.
*
- * SCXML documents (more generically, UML state chart diagrams) can be
+ * SCXML documents (more generically, UML state chart diagrams) can be
* used to define stateful behavior of objects, and Commons SCXML enables
* developers to use this model directly into the corresponding code
* artifacts. The resulting artifacts tend to be much simpler, embody
* a useful separation of concerns and are easier to understand and
* maintain. As the size of the modeled entity grows, these benefits
- * become more apparent.
+ * become more apparent.
*
- * This approach functions by registering an SCXMLListener that gets
+ * This approach functions by registering an SCXMLListener that gets
* notified onentry, and calls the namesake method for each state that
- * has been entered.
+ * has been entered.
*
- * This class swallows all exceptions only to log them. Developers of
+ * This class swallows all exceptions only to log them. Developers of
* subclasses should think of themselves as "component developers"
* catering to other end users, and therefore ensure that the subclasses
* are free of ModelExceptions and the like. Most methods
- * are protected for ease of subclassing.
+ * are protected for ease of subclassing.
*
*/
public abstract class AbstractStateMachine {
@@ -67,7 +67,7 @@
/**
* The state machine that will drive the instances of this class.
*/
-private static SCXML stateMachine;
+private SCXML stateMachine;
/**
* The instance specific SCXML engine.
@@ -92,7 +92,7 @@
private static final Object[] PARAMETERS = new Object[0];
/**
- * Convenience constructor.
+ * Convenience constructor, object instantiation incurs parsing cost.
*
* @param scxmlDocument The URL pointing to the SCXML document that
* describes the "lifecycle" of the
@@ -104,7 +104,7 @@
}
/**
- * Primary constructor.
+ * Primary constructor, object instantiation incurs parsing cost.
*
* @param scxmlDocument The URL pointing to the SCXML document that
* describes the "lifecycle" of the
@@ -118,20 +118,58 @@
public AbstractStateMachine(final URL scxmlDocument,
final Context rootCtx, final Evaluator evaluator) {
log = LogFactory.getLog(this.getClass());
-if (stateMachine == null) {
-// parse only once per subclass
-ErrorHandler errHandler = new SimpleErrorHandler();
-try {
-stateMachine = SCXMLDigester.digest(scxmlDocument,
-errHandler);
-} catch (IOException ioe) {
-logError(ioe);
-} catch (SAXException sae) {
-logError(sae);
-} catch (ModelException me) {
-logError(me);
-}
+ErrorHandler errHandler = new SimpleErrorHandler();
+try {
+sta
Re: Invitation to join the Apache Commons PMC
Process-wise, the chair might need to ascertain the board's lazy consensus. But, you probably know better. To if I'm interested -- yes, thanks, I intend to remain involved. -Rahul On 6/24/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: Hi Rahul, You've been nominated to become a part of the Apache Commons PMC and the vote has passed. Would you be interested in accepting the nomination? We understand that you were not in favour of the Commons TLP but, since the board has now passed the Commons resolution, hope that you still want to be involved with Commons and will accept this nomination -Niall, on behalf of the Commons PMC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
On 6/24/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Rahul Akolkar wrote: > On 6/23/07, Phil Steitz <[EMAIL PROTECTED]> wrote: >> On 6/23/07, Rahul Akolkar <[EMAIL PROTECTED]> wrote: >> > >> > >> > I haven't yet understood why we need to release anything from the >> > sandbox at all. Sure, reproducibility is a good thing, but I doubt the >> > builds are radically irreproducible without this release; and more >> > importantly, I believe if people are interested in the sandbox >> > components and their reproducibility, they should help get a release >> > out instead. >> > >> >> I think you have a good point there, Rahul, but I would see this as a >> commons release, not a commons-sandbox release and I personally see >> the benefit (consistent builds, easier to get a sandbox component to >> build when jumping in) as outweighing the negatives (increasing >> likelihood people depend on sandbox components, making the sandbox >> more "comfortable"), especially given that we are *not* releasing any >> sandbox jars. >> > > > I appreciate you taking the time to elaborate. I am not impressed by > any of these benefits (I'm not trying to be curt, I don't know how > else to put it). Moreover, I agree about the negatives. So what are the negatives here? I have not seen anyone put forward any arguments yet as to why releasing the sandbox parent pom would be bad. We are *not* talking about releasing sandbox components! Please, enlighten me. See line below, and less importantly, some comments above. > I see this as being distilled, and worse -- recurring, busy work. Well, Carlos asked for a release of the pom. I imagine that he has a good reason for this. imagine? I can only go by reasons stated in this thread (Carlos' and Phil's subsequent posts do not have a new reason IMO). So I stepped up to do the release. If I don't mind doing the job - why should you care? Because this is a Commons release. Because (as a more general statement beyond the ASF workings) I believe that merely having someone available to do something, does not by itself, make doing that thing worthwhile. Because (in terms of the ASF workings) do-ocracies do not imply that others should not care about what you are doing when its about releasing artifacts. Because we will have to: * Release periodically - Needs process cycles: RMs, votes (thanks for your cycles on this one) - Who knows how often this will have to happen (lesser the better) * Update all sandbox component POMs to keep parent versions in sync etc. I vote: -0 (non-binding) -Rahul -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
On 6/23/07, Phil Steitz <[EMAIL PROTECTED]> wrote: On 6/23/07, Wendy Smoak <[EMAIL PROTECTED]> wrote: > On 6/23/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > > > This will be the first release and is important because it enables > > reproducible builds and site generation for the sandbox components. > > Since you have a policy against releasing sandbox components, why not > just deploy snapshots of the sandbox parent pom, and advance to the > next snapshot version (without a release) when there is a change? > I guess the issue there is that you then have to add the snapshot repo explicitly just to *build* a sandbox component or generate its web site. We want to force people to do that if they *depend* on sandbox jars, but just building a sandbox component should not require it IMO. And it doesn't require that to build either -- install the parent. I suspect anyone who has used m2 even minimally is aware of the bootstrapping problems with development builds and how to solve them. For everyone else (and I'm sure we will get questions), the sandbox components should have 'install parent pom' as step 0 of their 'building' pages. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
On 6/23/07, Phil Steitz <[EMAIL PROTECTED]> wrote: On 6/23/07, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > > I haven't yet understood why we need to release anything from the > sandbox at all. Sure, reproducibility is a good thing, but I doubt the > builds are radically irreproducible without this release; and more > importantly, I believe if people are interested in the sandbox > components and their reproducibility, they should help get a release > out instead. > I think you have a good point there, Rahul, but I would see this as a commons release, not a commons-sandbox release and I personally see the benefit (consistent builds, easier to get a sandbox component to build when jumping in) as outweighing the negatives (increasing likelihood people depend on sandbox components, making the sandbox more "comfortable"), especially given that we are *not* releasing any sandbox jars. I appreciate you taking the time to elaborate. I am not impressed by any of these benefits (I'm not trying to be curt, I don't know how else to put it). Moreover, I agree about the negatives. I see this as being distilled, and worse -- recurring, busy work. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
On 6/23/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Hi, It is time to release version 1 of the commons-sandbox-parent. The latest changes includes updating the parent to commons-parent-3 and locking down the versions for plugins. Note that I have changed the artifactId to commons-sandbox-parent, to have a consistent naming scheme (compare it to commons-parent). This will be the first release and is important because it enables reproducible builds and site generation for the sandbox components. I haven't yet understood why we need to release anything from the sandbox at all. Sure, reproducibility is a good thing, but I doubt the builds are radically irreproducible without this release; and more importantly, I believe if people are interested in the sandbox components and their reproducibility, they should help get a release out instead. -Rahul This vote is for revision 550041, which will have its version number changed to 1 when the release is done. A SNAPSHOT has been deployed to the Apache snapshot repo if you want to take it for a spin. [ ] +1 [ ] =0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCXML] Relation between data model names and event names ?
On 6/23/07, Ingmar Kliche <[EMAIL PROTECTED]> wrote: > I understand there are some subtleties here, and the above definitely > needs to be better documented. If you want to help, feel free to add > some of your recent experiences and some of the pitfalls to the > Commons SCXML wiki [1] by creating a new page (you'll need to create > an account to log in, if you don't already have one). > > > -Rahul > > [1] http://wiki.apache.org/jakarta-commons/SCXML I'll try to write some comments within the near future. BTW: Are there any other pitfalls or "features" in commons-scxml which extending the (current) standard? :-) I'd say understanding the consequence of event names and the internal events generated tops the list (both of which we discussed in this thread). Other than that, there are expression language related good housekeeping bits that you will never find mentioned in the spec (such as variable names shouldn't contain dots -- which is more a side-effect of using JEXL or EL rather than anything else). The wiki page doesn't have to be comprehensive, just a starting point. -Rahul - Ingmar. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons Modeler 2.0.1 RC2
+1 (non-binding) -Rahul On 6/21/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: I have created a second release candidate for Modeler 2.0.1 following the problem Phil found in the first RC. Commons Modeler 2.0 didn't include the "ant.properties" file in the jar which is causing problems in Tomcat. Modeler 2.0.1 is a minor bug fix release fully backwards compatible to fix that issue and a few other build problems - full details in the release notes. Release Notes: http://people.apache.org/~niallp/modeler-2.0.1-rc2/RELEASE-NOTES.txt The artifacts being voted on are here: http://people.apache.org/~niallp/modeler-2.0.1-rc2/ Site: http://people.apache.org/~niallp/modeler-2.0.1-rc2/site/ RAT Report: http://people.apache.org/~niallp/modeler-2.0.1-rc2/rat-commons-modeler-2.0.1-src.txt [ ] +1 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons Modeler 2.0.1 RC1
+1 (non-binding) Sum and sigs I checked look good, site has 2.0.1 bits, source dists. -Rahul On 6/21/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: Commons Modeler 2.0 didn't include the "ant.properties" file in the jar which is causing problems in Tomcat. Modeler 2.0.1 is a minor bug fix release fully backwards compatible to fix that issue and a few other build problems - full details in the release notes. Release Notes: http://people.apache.org/~niallp/modeler-2.0.1-rc1/RELEASE-NOTES.txt The artifacts being voted on are here: http://people.apache.org/~niallp/modeler-2.0.1-rc1/ Site: http://people.apache.org/~niallp/modeler-2.0.1-rc1/site/ RAT Report: http://people.apache.org/~niallp/modeler-2.0.1-rc1/rat-commons-modeler-2.0.1-src.txt [ ] +1 [ ] -1 Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SCXML-47) Provide a state machine support class to allow for delegation.
[
https://issues.apache.org/jira/browse/SCXML-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506990
]
Rahul Akolkar commented on SCXML-47:
Looks good, a few minutiae:
* Perhaps it is better to have the name elaborate that the support is for
authoring classes that model stateful entities (and the operations performed in
those states). Do you think the name ClassStateMachineSupport makes more sense?
It does to me, but I'm not very good with names.
* The StateMachineSupport class (new name TBD) needs a ton of Javadoc at the
class level so folks can get a hang of whats in there (thanks for the new
method Javadocs). Some of your usage code snippets in the opening description
of this issue would also help a lot as part of that Javadoc.
* Code has unused imports (and some other warnings from my IDE about unused
stuff that are probably bogus)
* We should have only one AbstractStateMachine class (the current one can
extend StateMachineSupport and we'll be done with that). I don't see what we
can do about your constructors being a bit messy comment (I think we'll leave
them the way you have them).
Do you want to make these changes? I can too, but I can't say when.
> Provide a state machine support class to allow for delegation.
> --
>
> Key: SCXML-47
> URL: https://issues.apache.org/jira/browse/SCXML-47
> Project: Commons SCXML
> Issue Type: Improvement
>Affects Versions: 0.6
>Reporter: Michael Heuer
>Priority: Minor
> Fix For: 0.7
>
> Attachments: state-machine-support-src.tar.gz
>
>
> This is not completely thought out yet, but if folks like the idea I might
> persue it further.
> I would like to use AbstractStateMachine but cannot extend from it:
> class B extends A /*, AbstractStateMachine */ {
> // copy source from AbstractStateMachine here
> }
> I propose here a StateMachineSupport class that provides for use by
> subclassing and for use by delegation. The constructors are a little messy,
> but in the end I have
> public class StateMachineSupport {
> // use by subclassing
> protected StateMachineSupport(...) {
> }
> // use by delegation
> public StateMachineSupport(Object delegator, ...) {
> }
> // ... methods from AbstractStateMachine
> }
> public abstract class AbstractStateMachine extends StateMachineSupport {
> protected AbstractStateMachine(...) {
> super(...);
> }
> }
> // use by subclassing
> class ConcreteStateMachine extends AbstractStateMachine {
> ConcreteStateMachine() {
> super(..."stopwatch.xml");
> }
> public void reset() { ... }
> public void running() { ... }
> public void paused() { ... }
> public void stopped() { ... }
> }
> // use by delegation
> class DelegatingStateMachine extends SomethingElse {
> StateMachineSupport delegate;
> DelegatingStateMachine() {
> delegate = new StateMachineSupport(this, ..."stopwatch.xml");
> }
> public void reset() { ... }
> public void running() { ... }
> public void paused() { ... }
> public void stopped() { ... }
> }
> StateMachineSupport.java, AbstractStateMachine2.java,
> StateMachineSupportTest.java, and AbstractStateMachine2Test.java attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Are positive votes valid for further RC`s?
On 6/19/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: Hi, I'd like to bring up an issue from the vote on commons-io: Henri Yandell wrote: > > Personally I feel that when voting on a new rc dist, the previous +1s > still count (by lazyness) and its really about converting the -1s over > to +1s. > > How do others think here? It would certainly save a lot of time, given the fact that commons developers tend to ignore RC votes with increasing numbers. No, they don't count since the bits have changed. Perhaps that is incentive to try to keep the numbers from increasing too much. Release checking is becoming more and more tedious (with the advent of multi-module m2 builds), but we will have to address that separately. -Rahul Thanks, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Testing maven-artifact-manager patches
Wrong list? On 6/19/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: Hi, I'd like to test a patch for the maven-artifact-manager. My first though was to simply build Maven 2.0.7 from source, but that fails. Is there any other possibility to test my patch? Thanks, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] 3rd attempt: Release commons-io 1.3.2
On 6/19/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: Hi, Here's the result of the vote: +1: Sebb, Oliver, Niall, Ben, Myself And +1 from Gary in another thread [1] -- though in a subsequent post in the same thread he does express some interest in having the version number be 1.4. -1: Stephen No votes from Henri and Dion. My understanding is, that Stephen's vote isn't counted as a veto, but I'd like to ask you to correct me, if I'm wrong. In which case the vote had failed. Correct, it isn't a veto. In this case, it is upto you (being the RM) to decide whether to go ahead with putting the bits on the mirrors etc. since you have the required votes. I did not understand your comment about the version number [2] as it relates to whether deprecations should preclude release++ from being a point release. Regardless of what you choose to do here, we should (collectively) form an opinion and clarify this in the versioning guide for future reference. I am of the opinion that it shouldn't be a point release. -Rahul [1] http://www.nabble.com/RE%3A-Still-no-votes%21-%28WAS%3A--VOTE--3rd-attempt%3A-Release-commons-io-1.3.2%29-p11091530.html [2] http://www.nabble.com/Re%3A-Still-no-votes%21-%28WAS%3A--VOTE--3rd-attempt%3A-Release-commons-io-1.3.2%29-p11093009.html Thanks, Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SCXML-47) Provide a state machine support class to allow for delegation.
[
https://issues.apache.org/jira/browse/SCXML-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505907
]
Rahul Akolkar commented on SCXML-47:
Thanks, I can confirm that your CLA has been received (and recorded). I intend
to take a look at the attachment and post any comments later in the week.
> Provide a state machine support class to allow for delegation.
> --
>
> Key: SCXML-47
> URL: https://issues.apache.org/jira/browse/SCXML-47
> Project: Commons SCXML
> Issue Type: Improvement
>Affects Versions: 0.6
>Reporter: Michael Heuer
>Priority: Minor
> Fix For: 0.7
>
> Attachments: state-machine-support-src.tar.gz
>
>
> This is not completely thought out yet, but if folks like the idea I might
> persue it further.
> I would like to use AbstractStateMachine but cannot extend from it:
> class B extends A /*, AbstractStateMachine */ {
> // copy source from AbstractStateMachine here
> }
> I propose here a StateMachineSupport class that provides for use by
> subclassing and for use by delegation. The constructors are a little messy,
> but in the end I have
> public class StateMachineSupport {
> // use by subclassing
> protected StateMachineSupport(...) {
> }
> // use by delegation
> public StateMachineSupport(Object delegator, ...) {
> }
> // ... methods from AbstractStateMachine
> }
> public abstract class AbstractStateMachine extends StateMachineSupport {
> protected AbstractStateMachine(...) {
> super(...);
> }
> }
> // use by subclassing
> class ConcreteStateMachine extends AbstractStateMachine {
> ConcreteStateMachine() {
> super(..."stopwatch.xml");
> }
> public void reset() { ... }
> public void running() { ... }
> public void paused() { ... }
> public void stopped() { ... }
> }
> // use by delegation
> class DelegatingStateMachine extends SomethingElse {
> StateMachineSupport delegate;
> DelegatingStateMachine() {
> delegate = new StateMachineSupport(this, ..."stopwatch.xml");
> }
> public void reset() { ... }
> public void running() { ... }
> public void paused() { ... }
> public void stopped() { ... }
> }
> StateMachineSupport.java, AbstractStateMachine2.java,
> StateMachineSupportTest.java, and AbstractStateMachine2Test.java attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] svn commit: r548098 - in /jakarta/commons/proper/configuration/trunk: src/java/org/apache/commons/configuration/ xdocs/ xdocs/userguide/
On 6/17/07, Oliver Heger <[EMAIL PROTECTED]> wrote: How about: "The most concrete implementations of the Configuration interface that are shipped with this library are not thread-safe. They can be accessed concurrently in a read-only manner. However if one thread modifies a configuration object, manual synchronization has to be performed to ensure correctness of data." Yup, thanks! -Rahul Oliver BTW: Thanks for the hint. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] svn commit: r548098 - in /jakarta/commons/proper/configuration/trunk: src/java/org/apache/commons/configuration/ xdocs/ xdocs/userguide/
On 6/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: oheger Date: Sun Jun 17 12:34:03 2007 New Revision: 548098 URL: http://svn.apache.org/viewvc?view=rev&rev=548098 Log: Javadoc only: added notes about thread-safety to the most important Configuration implementations + + + +The most concrete implementations of the Configuration +interface that are shipped with this library are thread-safe as long as +they are accessed in a read-only manner. However if one thread +modifies a configuration object, manual synchronization has to be +performed to ensure correctness of data. Notes about the thread +safety of conrete implementation classes can be found in the Javadocs +for these classes. + + I think the first sentence should simply state that most implementations are not thread-safe (rather than the read-only bit which I found unnecessary, perhaps confusing). WDYT? -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SCXML-47) Provide a state machine support class to allow for delegation.
[
https://issues.apache.org/jira/browse/SCXML-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rahul Akolkar updated SCXML-47:
---
Fix Version/s: 0.7
Affects Version/s: 0.6
Tentatively setting fix version to v0.7.
> Provide a state machine support class to allow for delegation.
> --
>
> Key: SCXML-47
> URL: https://issues.apache.org/jira/browse/SCXML-47
> Project: Commons SCXML
> Issue Type: Improvement
>Affects Versions: 0.6
>Reporter: Michael Heuer
>Priority: Minor
> Fix For: 0.7
>
> Attachments: state-machine-support-src.tar.gz
>
>
> This is not completely thought out yet, but if folks like the idea I might
> persue it further.
> I would like to use AbstractStateMachine but cannot extend from it:
> class B extends A /*, AbstractStateMachine */ {
> // copy source from AbstractStateMachine here
> }
> I propose here a StateMachineSupport class that provides for use by
> subclassing and for use by delegation. The constructors are a little messy,
> but in the end I have
> public class StateMachineSupport {
> // use by subclassing
> protected StateMachineSupport(...) {
> }
> // use by delegation
> public StateMachineSupport(Object delegator, ...) {
> }
> // ... methods from AbstractStateMachine
> }
> public abstract class AbstractStateMachine extends StateMachineSupport {
> protected AbstractStateMachine(...) {
> super(...);
> }
> }
> // use by subclassing
> class ConcreteStateMachine extends AbstractStateMachine {
> ConcreteStateMachine() {
> super(..."stopwatch.xml");
> }
> public void reset() { ... }
> public void running() { ... }
> public void paused() { ... }
> public void stopped() { ... }
> }
> // use by delegation
> class DelegatingStateMachine extends SomethingElse {
> StateMachineSupport delegate;
> DelegatingStateMachine() {
> delegate = new StateMachineSupport(this, ..."stopwatch.xml");
> }
> public void reset() { ... }
> public void running() { ... }
> public void paused() { ... }
> public void stopped() { ... }
> }
> StateMachineSupport.java, AbstractStateMachine2.java,
> StateMachineSupportTest.java, and AbstractStateMachine2Test.java attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SCXML-47) Provide a state machine support class to allow for delegation.
[
https://issues.apache.org/jira/browse/SCXML-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505507
]
Rahul Akolkar commented on SCXML-47:
Sounds useful; the AbstractStateMachine class hasn't been used much by me (it
was put together for the stopwatch usecase) but I know others are using it. I
believe many improvements are possible -- at some point, when we move to JDK
1.5, we can take care of some of this with annotations instead which perhaps
may be cleaner.
To begin, could you fill out an Individual Contributor License Agreement
(ICLA)? That is here (the fax number is on the form itself, you can mail it in
too if you want):
http://www.apache.org/licenses/icla.txt
Its a one-time thing, and is needed for non-trivial contributions, for code
provenance and pedigree reasons. Please let us know if you have any questions
about the ICLA. Ping this issue when you send it in (unless you choose not to),
then we can track its receipt and dig into the details of this improvement.
Thanks.
> Provide a state machine support class to allow for delegation.
> --
>
> Key: SCXML-47
> URL: https://issues.apache.org/jira/browse/SCXML-47
> Project: Commons SCXML
> Issue Type: Improvement
>Reporter: Michael Heuer
>Priority: Minor
> Attachments: state-machine-support-src.tar.gz
>
>
> This is not completely thought out yet, but if folks like the idea I might
> persue it further.
> I would like to use AbstractStateMachine but cannot extend from it:
> class B extends A /*, AbstractStateMachine */ {
> // copy source from AbstractStateMachine here
> }
> I propose here a StateMachineSupport class that provides for use by
> subclassing and for use by delegation. The constructors are a little messy,
> but in the end I have
> public class StateMachineSupport {
> // use by subclassing
> protected StateMachineSupport(...) {
> }
> // use by delegation
> public StateMachineSupport(Object delegator, ...) {
> }
> // ... methods from AbstractStateMachine
> }
> public abstract class AbstractStateMachine extends StateMachineSupport {
> protected AbstractStateMachine(...) {
> super(...);
> }
> }
> // use by subclassing
> class ConcreteStateMachine extends AbstractStateMachine {
> ConcreteStateMachine() {
> super(..."stopwatch.xml");
> }
> public void reset() { ... }
> public void running() { ... }
> public void paused() { ... }
> public void stopped() { ... }
> }
> // use by delegation
> class DelegatingStateMachine extends SomethingElse {
> StateMachineSupport delegate;
> DelegatingStateMachine() {
> delegate = new StateMachineSupport(this, ..."stopwatch.xml");
> }
> public void reset() { ... }
> public void running() { ... }
> public void paused() { ... }
> public void stopped() { ... }
> }
> StateMachineSupport.java, AbstractStateMachine2.java,
> StateMachineSupportTest.java, and AbstractStateMachine2Test.java attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r547819 - /jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/model/State.java
Author: rahul
Date: Fri Jun 15 15:26:50 2007
New Revision: 547819
URL: http://svn.apache.org/viewvc?view=rev&rev=547819
Log:
Adding Javadoc links for easier navigation.
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/model/State.java
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/model/State.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/model/State.java?view=diff&rev=547819&r1=547818&r2=547819
==
---
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/model/State.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/model/State.java
Fri Jun 15 15:26:50 2007
@@ -197,7 +197,7 @@
* Get the map of all outgoing transitions from this state.
*
* @return Map Returns the transitions Map.
- * @deprecated Use getTransitionsList() instead
+ * @deprecated Use [EMAIL PROTECTED] #getTransitionsList()} instead
*/
public final Map getTransitions() {
Map transitionsMap = new HashMap();
@@ -264,7 +264,7 @@
* @param state
*a child state
*
- * @deprecated Use addChild(TransitionTarget) instead.
+ * @deprecated Use [EMAIL PROTECTED] #addChild(TransitionTarget)} instead.
*/
public final void addChild(final State state) {
this.children.put(state.getId(), state);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SCXML-44) Interface consistency: State.getIsFinal and State.setIsFinal
[ https://issues.apache.org/jira/browse/SCXML-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Akolkar updated SCXML-44: --- Fix Version/s: (was: 0.7) 1.0 Suggested changes have been made. Original methods are now deprecated. Setting fix version to v1.0 when deprecations can be removed. > Interface consistency: State.getIsFinal and State.setIsFinal > > > Key: SCXML-44 > URL: https://issues.apache.org/jira/browse/SCXML-44 > Project: Commons SCXML > Issue Type: Improvement >Affects Versions: 0.6 >Reporter: Jörg Weinmann >Priority: Trivial > Fix For: 1.0 > > > Getter and setter method for boolean isFinal is inconsistent to similiar > getter and setter methods in the class. > I would have expected: State.isFinal() and State.setFinal(). > Compare to isDone(), isSimple(), isDone(), setDone(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r547816 - in /jakarta/commons/proper/scxml/trunk/src: main/java/org/apache/commons/scxml/ main/java/org/apache/commons/scxml/io/ main/java/org/apache/commons/scxml/model/ main/java/org/apa
Author: rahul
Date: Fri Jun 15 15:21:12 2007
New Revision: 547816
URL: http://svn.apache.org/viewvc?view=rev&rev=547816
Log:
Inconsistency: State.getIsFinal and State.setIsFinal
SCXML-44
While its a pain to change method names, I agree the existing ones are bogus
and I'd rather improve for v1.0.
- Initiating deprecation cycle for older variants
- Removing any internal usage of the now deprecated methods
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/Status.java
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLDigester.java
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLParser.java
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLSerializer.java
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/model/Final.java
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/model/State.java
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLExecutorTest.java
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/StatusTest.java
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/Status.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/Status.java?view=diff&rev=547816&r1=547815&r2=547816
==
---
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/Status.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/Status.java
Fri Jun 15 15:21:12 2007
@@ -58,7 +58,7 @@
boolean rslt = true;
for (Iterator i = states.iterator(); i.hasNext();) {
State s = (State) i.next();
-if (!s.getIsFinal()) {
+if (!s.isFinal()) {
rslt = false;
break;
}
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLDigester.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLDigester.java?view=diff&rev=547816&r1=547815&r2=547816
==
---
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLDigester.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLDigester.java
Fri Jun 15 15:21:12 2007
@@ -952,7 +952,7 @@
public void end(final String namespace, final String name) {
Transition t = (Transition) getDigester().peek(1);
State exitState = new State();
-exitState.setIsFinal(true);
+exitState.setFinal(true);
t.getTargets().add(exitState);
}
});
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLParser.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLParser.java?view=diff&rev=547816&r1=547815&r2=547816
==
---
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLParser.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLParser.java
Fri Jun 15 15:21:12 2007
@@ -959,7 +959,7 @@
public void end(final String namespace, final String name) {
Transition t = (Transition) getDigester().peek(1);
State exitState = new State();
-exitState.setIsFinal(true);
+exitState.setFinal(true);
t.getTargets().add(exitState);
}
});
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLSerializer.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLSerializer.java?view=diff&rev=547816&r1=547815&r2=547816
==
---
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLSerializer.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLSerializer.java
Fri Jun 15 15:21:12 2007
@@ -125,7 +125,7 @@
final State s, final String indent) {
b.append(indent).append("http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/s
[jira] Resolved: (SCXML-46) Provide a SCXMLListener abstract adapter class.
[ https://issues.apache.org/jira/browse/SCXML-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Akolkar resolved SCXML-46. Resolution: Fixed Added, under the new name AbstractSCXMLListener. Thanks for the contribution. > Provide a SCXMLListener abstract adapter class. > --- > > Key: SCXML-46 > URL: https://issues.apache.org/jira/browse/SCXML-46 > Project: Commons SCXML > Issue Type: Improvement >Affects Versions: 0.6 >Reporter: Michael Heuer >Assignee: Rahul Akolkar >Priority: Trivial > Fix For: 0.7 > > Attachments: SCXMLAdapter.java, SCXMLAdapterTest.java > > > Attached are new files SCMLAdapter.java and SCXMLAdapterTest.java > Might also want to add > + suite.addTest(SCXMLAdapterTest.suite()); > to SCXMLTestSuite.java, line 54 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r547799 - in /jakarta/commons/proper/scxml/trunk: ./ src/main/java/org/apache/commons/scxml/env/ src/test/java/org/apache/commons/scxml/env/
Author: rahul
Date: Fri Jun 15 14:43:38 2007
New Revision: 547799
URL: http://svn.apache.org/viewvc?view=rev&rev=547799
Log:
Provide a SCXMLListener abstract adapter class
SCXML-46
Thanks to Michael Heuer .
Added Michael to the list of contributors.
Added:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/AbstractSCXMLListener.java
(with props)
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/AbstractSCXMLListenerTest.java
(with props)
Modified:
jakarta/commons/proper/scxml/trunk/pom.xml
jakarta/commons/proper/scxml/trunk/project.xml
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/EnvTestSuite.java
Modified: jakarta/commons/proper/scxml/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/pom.xml?view=diff&rev=547799&r1=547798&r2=547799
==
--- jakarta/commons/proper/scxml/trunk/pom.xml (original)
+++ jakarta/commons/proper/scxml/trunk/pom.xml Fri Jun 15 14:43:38 2007
@@ -78,6 +78,9 @@
Nestor Urquiza
+
+ Michael Heuer
+
Modified: jakarta/commons/proper/scxml/trunk/project.xml
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/project.xml?view=diff&rev=547799&r1=547798&r2=547799
==
--- jakarta/commons/proper/scxml/trunk/project.xml (original)
+++ jakarta/commons/proper/scxml/trunk/project.xml Fri Jun 15 14:43:38 2007
@@ -113,6 +113,9 @@
Nestor Urquiza
+
+ Michael Heuer
+
Added:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/AbstractSCXMLListener.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/AbstractSCXMLListener.java?view=auto&rev=547799
==
---
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/AbstractSCXMLListener.java
(added)
+++
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/AbstractSCXMLListener.java
Fri Jun 15 14:43:38 2007
@@ -0,0 +1,53 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.scxml.env;
+
+import org.apache.commons.scxml.SCXMLListener;
+import org.apache.commons.scxml.model.Transition;
+import org.apache.commons.scxml.model.TransitionTarget;
+
+/**
+ * An abstract adapter class for the SXCMLListener interface.
+ * This class exists as a convenience for creating listener objects, and as
+ * such all the methods in this class are empty.
+ */
+public abstract class AbstractSCXMLListener implements SCXMLListener {
+
+/**
+ * @see SCXMLListener#onEntry(TransitionTarget)
+ */
+public void onEntry(final TransitionTarget state) {
+// empty
+}
+
+/**
+ * @see SCXMLListener#onExit(TransitionTarget)
+ */
+public void onExit(final TransitionTarget state) {
+// empty
+}
+
+/**
+* @see SCXMLListener#onTransition(TransitionTarget,TransitionTarget,Transition)
+ */
+public void onTransition(final TransitionTarget from,
+final TransitionTarget to, final Transition transition) {
+// empty
+}
+
+}
+
Propchange:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/AbstractSCXMLListener.java
--
svn:eol-style = native
Propchange:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/AbstractSCXMLListener.java
--
svn:keywords = Date Author Id Revision HeadURL
Added:
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/AbstractSCXMLListenerTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env
[jira] Resolved: (SCXML-41) Adding information to evaluation error messages
[ https://issues.apache.org/jira/browse/SCXML-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Akolkar resolved SCXML-41. Resolution: Fixed The error message now contains the offending expression as well. > Adding information to evaluation error messages > --- > > Key: SCXML-41 > URL: https://issues.apache.org/jira/browse/SCXML-41 > Project: Commons SCXML > Issue Type: Improvement >Affects Versions: 0.6 >Reporter: Nestor Urquiza >Assignee: Rahul Akolkar > Fix For: 0.7 > > > Log trace like: > EXPRESSION_ERROR (java.lang.NullPointerException) > > > We could output more than just > he little message that comes from JEXL if we modify > JexlEvaluator#eval() to output the expr parameter when > an Exception occurs. > That way one can see easy the culprit line of JEXL/EL > code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r547791 - in /jakarta/commons/proper/scxml/trunk/src: main/java/org/apache/commons/scxml/env/jexl/ main/java/org/apache/commons/scxml/env/jsp/ test/java/org/apache/commons/scxml/env/jexl/
Author: rahul
Date: Fri Jun 15 14:31:30 2007
New Revision: 547791
URL: http://svn.apache.org/viewvc?view=rev&rev=547791
Log:
Adding information to evaluation error messages
SCXML-41
Also added tests for the evaluators, including those that make sure that the
failing expression is echoed in the error message.
Added:
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/jexl/JexlEvaluatorTest.java
(with props)
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/jsp/ELEvaluatorTest.java
(with props)
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/jexl/JexlEvaluator.java
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/jsp/ELEvaluator.java
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/jexl/EnvJexlTestSuite.java
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/jsp/EnvJspTestSuite.java
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/jexl/JexlEvaluator.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/jexl/JexlEvaluator.java?view=diff&rev=547791&r1=547790&r2=547791
==
---
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/jexl/JexlEvaluator.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/jexl/JexlEvaluator.java
Fri Jun 15 14:31:30 2007
@@ -83,7 +83,8 @@
exp = ExpressionFactory.createExpression(evalExpr);
return exp.evaluate(getEffectiveContext(jexlCtx));
} catch (Exception e) {
-throw new SCXMLExpressionException(e);
+throw new SCXMLExpressionException("eval('" + expr + "'):"
++ e.getMessage(), e);
}
}
@@ -110,7 +111,8 @@
exp = ExpressionFactory.createExpression(evalExpr);
return (Boolean) exp.evaluate(getEffectiveContext(jexlCtx));
} catch (Exception e) {
-throw new SCXMLExpressionException(e);
+throw new SCXMLExpressionException("eval('" + expr + "'):"
++ e.getMessage(), e);
}
}
@@ -139,7 +141,8 @@
exp = ExpressionFactory.createExpression(evalExpr);
return (Node) exp.evaluate(getEffectiveContext(jexlCtx));
} catch (Exception e) {
-throw new SCXMLExpressionException(e);
+throw new SCXMLExpressionException("eval('" + expr + "'):"
++ e.getMessage(), e);
}
}
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/jsp/ELEvaluator.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/jsp/ELEvaluator.java?view=diff&rev=547791&r1=547790&r2=547791
==
---
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/jsp/ELEvaluator.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/env/jsp/ELEvaluator.java
Fri Jun 15 14:31:30 2007
@@ -110,7 +110,8 @@
}
return rslt;
} catch (ELException e) {
-throw new SCXMLExpressionException(e);
+throw new SCXMLExpressionException("eval('" + expr + "'):"
++ e.getMessage(), e);
}
}
@@ -140,7 +141,8 @@
}
return rslt;
} catch (ELException e) {
-throw new SCXMLExpressionException(e);
+throw new SCXMLExpressionException("eval('" + expr + "'):"
++ e.getMessage(), e);
}
}
@@ -172,7 +174,8 @@
}
return rslt;
} catch (ELException e) {
-throw new SCXMLExpressionException(e);
+throw new SCXMLExpressionException("eval('" + expr + "'):"
++ e.getMessage(), e);
}
}
Modified:
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/jexl/EnvJexlTestSuite.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/jexl/EnvJexlTestSuite.java?view=diff&rev=547791&r1=547790&r2=547791
==
---
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/jexl/EnvJexlTestSuite.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/jex
svn commit: r547758 - in /jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml: io/ModelUpdater.java io/SCXMLParser.java io/SCXMLSerializer.java model/SCXML.java model/State.java
Author: rahul
Date: Fri Jun 15 11:26:11 2007
New Revision: 547758
URL: http://svn.apache.org/viewvc?view=rev&rev=547758
Log:
Correcting various checkstyle errors and Javadoc warnings.
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/ModelUpdater.java
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLParser.java
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLSerializer.java
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/model/SCXML.java
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/model/State.java
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/ModelUpdater.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/ModelUpdater.java?view=diff&rev=547758&r1=547757&r2=547758
==
---
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/ModelUpdater.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/ModelUpdater.java
Fri Jun 15 11:26:11 2007
@@ -77,7 +77,7 @@
if (tt instanceof State) {
updateState((State) tt, targets);
} else {
- updateParallel((Parallel) tt, targets);
+ updateParallel((Parallel) tt, targets);
}
}
}
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLParser.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLParser.java?view=diff&rev=547758&r1=547757&r2=547758
==
---
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLParser.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLParser.java
Fri Jun 15 11:26:11 2007
@@ -773,6 +773,10 @@
* @param xp The Digester style XPath expression of the parent
* XML element
* @param scxmlRules The rule set to be used for digestion
+ * @param customActions The list of custom actions this digester needs
+ * to be able to process
+ * @param scxml The parent SCXML document (or null)
+ * @param pr The [EMAIL PROTECTED] PathResolver} for this document
*/
private static void addFinalRules(final String xp,
final ExtendedBaseRules scxmlRules, final List customActions,
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLSerializer.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLSerializer.java?view=diff&rev=547758&r1=547757&r2=547758
==
---
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLSerializer.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLSerializer.java
Fri Jun 15 11:26:11 2007
@@ -107,7 +107,7 @@
if (tt instanceof State) {
serializeState(b, (State) tt, INDENT);
} else {
-serializeParallel(b, (Parallel) tt, INDENT);
+serializeParallel(b, (Parallel) tt, INDENT);
}
}
b.append("\n");
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/model/SCXML.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/model/SCXML.java?view=diff&rev=547758&r1=547757&r2=547758
==
---
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/model/SCXML.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/model/SCXML.java
Fri Jun 15 11:26:11 2007
@@ -106,7 +106,7 @@
/**
* Set the initial State.
*
- * @param initialTarget The initialstate to set.
+ * @param initialState The initialstate to set.
*
* @deprecated Use setInitialTarget(TransitionTarget) instead.
*/
@@ -184,7 +184,7 @@
/**
* Add an immediate child target of the SCXML root.
*
- * @param target The transition target to be added to the states Map.
+ * @param tt The transition target to be added to the states Map.
*/
public final void addChild(final TransitionTarget tt) {
children.put(tt.getId(), tt);
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/model/State.
[jira] Updated: (SCXML-46) Provide a SCXMLListener abstract adapter class.
[ https://issues.apache.org/jira/browse/SCXML-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Akolkar updated SCXML-46: --- Fix Version/s: 0.7 Affects Version/s: 0.6 > Provide a SCXMLListener abstract adapter class. > --- > > Key: SCXML-46 > URL: https://issues.apache.org/jira/browse/SCXML-46 > Project: Commons SCXML > Issue Type: Improvement >Affects Versions: 0.6 >Reporter: Michael Heuer >Assignee: Rahul Akolkar >Priority: Trivial > Fix For: 0.7 > > Attachments: SCXMLAdapter.java, SCXMLAdapterTest.java > > > Attached are new files SCMLAdapter.java and SCXMLAdapterTest.java > Might also want to add > + suite.addTest(SCXMLAdapterTest.suite()); > to SCXMLTestSuite.java, line 54 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (SCXML-46) Provide a SCXMLListener abstract adapter class.
[ https://issues.apache.org/jira/browse/SCXML-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505332 ] Rahul Akolkar commented on SCXML-46: Thanks for the addition and the tests. I think we should call the class AbstractSCXMLListener and put it in the oac.scxml.env package. OK? > Provide a SCXMLListener abstract adapter class. > --- > > Key: SCXML-46 > URL: https://issues.apache.org/jira/browse/SCXML-46 > Project: Commons SCXML > Issue Type: Improvement >Reporter: Michael Heuer >Assignee: Rahul Akolkar >Priority: Trivial > Attachments: SCXMLAdapter.java, SCXMLAdapterTest.java > > > Attached are new files SCMLAdapter.java and SCXMLAdapterTest.java > Might also want to add > + suite.addTest(SCXMLAdapterTest.suite()); > to SCXMLTestSuite.java, line 54 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons-compress] a release
On 6/13/07, Cyril <[EMAIL PROTECTED]> wrote: Hello all, I would like to know if a release is planned for this project as I'm interested. Thanks for your answers. Not to my knowledge. How to help [1]. -Rahul [1] http://jakarta.apache.org/site/getinvolved.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Versioining and compatibility WAS Re: [VOTE] Release CLI 1.1
On 6/13/07, Phil Steitz <[EMAIL PROTECTED]> wrote: Sorry, but I have to agree with Niall on this - needs to be 2.0 with the incompatible changes - and I would like very much for us to agree once and for all on some versioning/deprecation rules. We seem to have lost the old versioning guidelines (unless I am senile, we used to have these on the commons or Jakarta pages somewhere). We still do: http://jakarta.apache.org/commons/releases/versioning.html -Rahul Apart from 0), which is a conservative but worth-considering-carefully PoV, the rules below are more or less what we have been adhering to over the last several years in commons and I would like to propose that we standardize on them. If all are OK, I will gin up a versioning page. A very good one, which is pretty much a C version of what I am proposing below, is http://apr.apache.org/versioning.html. 0) Never break backward source or binary compatibility - i.e., when you need to, change the package name. 1) 0 is going to have to fail sometimes for practical reasons. When it does, fall back to a) no source, binary or semantic incompatibilities or deprecations introduced in a x.y.z release b) no source or binary incompatibilities in an x.y release, but deprecations and semantic changes allowed c) no removals without prior deprecations, but these and other backward incompatible changes allowed in x.0 releases. This means that the [cli] release with the current changes would need to be 2.0. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] email failed.
On 6/9/07, Phil Steitz <[EMAIL PROTECTED]> wrote: On 6/6/07, Ben Speakmon <[EMAIL PROTECTED]> wrote: > I'm moving the email nightly build to maven 2 and I'm putting together the > missing dependencies into upload bundles for repo.maven.org. When you have the m2 build working, just remove email from commons-nightly/nightly_proper_maven_list.txt and add it to commons-nightly/nightly_proper_maven2_list.txt and check these files in to svn. Then the script will start using m2 to build email nightly. If you want to turn off the m1 nightly build in the mean time, you can just do the first step. He switched in r545027 [1]. -Rahul [1] http://svn.apache.org/viewvc?view=rev&revision=545027 Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCXML] Relation between data model names and event names ?
Before we get into the specifics below, some background: * Event names imply an ontology. So an "error.foo" event is an "error" event, and so is the "error.foo.bar" event (which, in addition, is also a type of "error.foo" event). Therefore, the following transition ... ... will be followed if any of the following events are triggered on the state machine (because all of these are "error" events): - error - error.foo - error.bar - error.foo.bar.baz IMO, event names should be chosen scrupulously during the design of reactive systems keeping the above in mind. * The Commons SCXML implementation generates a .change event when a piece of any data model changes (similarly it generates a .entry when any state is entered and a .exit when a state is exited). Which means one can watch some part of the datamodel for an update for triggering a transition. This is quite useful for communicating across regions etc. Now, to answer your questions: On 6/8/07, Ingmar Kliche <[EMAIL PROTECTED]> wrote: Rahul, I have a strange behavior with one of my samples I'm currently playing with. I try generate a number of timer events (like a count down) using a variable in the data model and delayed events: This sample does not work as expected. All events are fired immediately and are not delayed. 'ing a new value to the named 'timer' generates a 'timer.change' event. The assumption of an ontology as stated above causes the to be immediately followed (all 5 of them, because there are 5 cascading s). I understand there are some subtleties here, and the above definitely needs to be better documented. If you want to help, feel free to add some of your recent experiences and some of the pitfalls to the Commons SCXML wiki [1] by creating a new page (you'll need to create an account to log in, if you don't already have one). As soon as I rename either the event name or the name of the data tag to "timer1" it works fine. I take it this is as expected, so doesn't need any further clarification :-) As soon as I use a dotted name for the data tag name attribute (e.g. "timer.id" while event="timer") it doesn't work again. 'Dotted names' are never recommended for use in documents with JEXL or EL expressions (so no dots in or names please). Both languages have a dot operator, and the evaluators get thrown off. -Rahul [1] http://wiki.apache.org/jakarta-commons/SCXML I have no clue why the data model names and the event names should be related. Is this intended? I'm using snapshot 0.7 -Ingmar. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [CLI] All those trunks
On 6/6/07, Henri Yandell <[EMAIL PROTECTED]> wrote: On 6/6/07, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > Hen, > > Looks like the cli-1.0.x branch is on its way. IMO, we should remove > the other two from trunks-proper. We could remove the avalon one. I don't think there's any sign that it'll ever have a release or development. The 2.x one is a tricky one. Once 1.1 is released we need to decide if 2.0 is the way forward etc; so I'd like to leave that one there if I could. Effectively we have two CLI components running in parallel at the moment. IMO we don't, until we release both (ATM, there are branches where some potentially successful experiments have been done, doesn't mean adding all of those to trunks-proper is of any value -- folks should just be checking out branches directly to work on them). In other words, we may be getting ahead of ourselves here. -Rahul Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [io][fileupload] svn commit: r518770 - in /jakarta/commons/proper/io/trunk/src: java/org/apache/commons/io/FileCleaningTracker.java test/org/apache/commons/io/FileUtilsCleanDirectoryTestCase.java
On 6/6/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: On 3/16/08, Rahul Akolkar wrote: > On 3/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Author: jochen > > Date: Thu Mar 15 15:02:46 2007 > > New Revision: 518770 > > I haven't really though about the fileupload part, but you have convinced me that this must be addressed by fileupload and not by io. I have therefore reverted my patch in the 1.3 branch. I will also revert the same patch in the trunk after the 1.3.2 release is out when I merge the release related changes in. OK, thanks. -Rahul Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[CLI] All those trunks
Hen, Looks like the cli-1.0.x branch is on its way. IMO, we should remove the other two from trunks-proper. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [CLI] svn commit: r544763 - in /jakarta/commons/proper/cli/branches/cli-1.0.x/src/test/org/apache/commons/cli: HelpFormatterTest.java TestHelpFormatter.java
On 6/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: bayard Date: Wed Jun 6 01:02:57 2007 New Revision: 544763 URL: http://svn.apache.org/viewvc?view=rev&rev=544763 Log: Renaming TestHelpFormatter to the more obvious HelpFormatterTest Added: jakarta/commons/proper/cli/branches/cli-1.0.x/src/test/org/apache/commons/cli/HelpFormatterTest.java (with props) Removed: jakarta/commons/proper/cli/branches/cli-1.0.x/src/test/org/apache/commons/cli/TestHelpFormatter.java Looks like we lost history here, though probably not much of a deal since its a test class. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli] Minimum JDK version for 1.1?
On 6/5/07, Henri Yandell <[EMAIL PROTECTED]> wrote: I'd like to move the minimum JDK version for CLI up to 1.4 for the CLI 1.1 release. Sounds good to me. -Rahul This would: a) Allow the fact that the build.xml does not work on 1.3 to be ignored. b) Allow CLI-131 to be applied. c) Make for an easier build - I can build directly in Maven and not worry about legacy. Anyone against? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [JEXL] svn commit: r543799 - in /jakarta/commons/proper/jelly/trunk/xdocs/style: ./ project.css
On 6/3/07, peter royal <[EMAIL PROTECTED]> wrote: On Jun 3, 2007, at 8:27 AM, Rahul Akolkar wrote: > On 6/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> Author: proyal >> Date: Sat Jun 2 15:59:58 2007 >> New Revision: 543799 >> >> URL: http://svn.apache.org/viewvc?view=rev&rev=543799 >> Log: >> add new project stylesheet >> > > > Missing props. I set eol-style.. doesn't need anything else, right? Yup, thats the one I cared about, thanks. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] releasing jci RC3 as 1.0 ...maybe this time?
On 6/2/07, Torsten Curdt <[EMAIL PROTECTED]> wrote: Votes ...someone? Should I provide a tgz so it's easier to grab? Not really for that purpose, but it would be good to have a complete source assembly. I'm not set to examine multi-module releases ATM. I've looked at these in other releases (outside Commons) where they are few and far away such that the overhead in showing due diligence and manually examining each artifact seems affordable. We have talked about automated release checkers (IIRC, you even mentioned you had some scripts) ... but I'm not there yet. Sorry for the aside, this being not pertinent to the vote in itself. -Rahul cheers -- Torsten On 31.05.2007, at 03:49, Torsten Curdt wrote: > Only pom and license header changes since RC2. We are voting on the > actual binaries for the release. > > http://jakarta.apache.org/commons/jci/ > > http://people.apache.org/builds/jakarta-commons/jci/1.0-RC3/org/ > apache/commons/commons-jci/1.0/ > http://people.apache.org/builds/jakarta-commons/jci/1.0-RC3/org/ > apache/commons/commons-jci-core/1.0/ > http://people.apache.org/builds/jakarta-commons/jci/1.0-RC3/org/ > apache/commons/commons-jci-fam/1.0/ > > http://people.apache.org/builds/jakarta-commons/jci/1.0-RC3/org/ > apache/commons/commons-jci-eclipse/1.0/ > http://people.apache.org/builds/jakarta-commons/jci/1.0-RC3/org/ > apache/commons/commons-jci-groovy/1.0/ > http://people.apache.org/builds/jakarta-commons/jci/1.0-RC3/org/ > apache/commons/commons-jci-janino/1.0/ > http://people.apache.org/builds/jakarta-commons/jci/1.0-RC3/org/ > apache/commons/commons-jci-javac/1.0/ > http://people.apache.org/builds/jakarta-commons/jci/1.0-RC3/org/ > apache/commons/commons-jci-rhino/1.0/ > > http://people.apache.org/builds/jakarta-commons/jci/1.0-RC3/org/ > apache/commons/commons-jci-examples/1.0/ > > Please cast you votes to release RC3. > > cheers > -- > Torsten > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] svn commit: r543805 - /jakarta/commons/proper/commons-parent/trunk/pom.xml
On 6/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: dennisl Date: Sat Jun 2 16:07:28 2007 New Revision: 543805 URL: http://svn.apache.org/viewvc?view=rev&rev=543805 Log: Put back the license. Rumor has it that putting the license comment as a child of the root is a workaround. Sounds plausible, is that true? -Rahul Modified: jakarta/commons/proper/commons-parent/trunk/pom.xml Modified: jakarta/commons/proper/commons-parent/trunk/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/commons-parent/trunk/pom.xml?view=diff&rev=543805&r1=543804&r2=543805 == --- jakarta/commons/proper/commons-parent/trunk/pom.xml (original) +++ jakarta/commons/proper/commons-parent/trunk/pom.xml Sat Jun 2 16:07:28 2007 @@ -1,3 +1,21 @@ + http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [JEXL] svn commit: r543799 - in /jakarta/commons/proper/jelly/trunk/xdocs/style: ./ project.css
On 6/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: proyal
Date: Sat Jun 2 15:59:58 2007
New Revision: 543799
URL: http://svn.apache.org/viewvc?view=rev&rev=543799
Log:
add new project stylesheet
Missing props.
-Rahul
Added:
jakarta/commons/proper/jelly/trunk/xdocs/style/
jakarta/commons/proper/jelly/trunk/xdocs/style/project.css
Added: jakarta/commons/proper/jelly/trunk/xdocs/style/project.css
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/jelly/trunk/xdocs/style/project.css?view=auto&rev=543799
==
--- jakarta/commons/proper/jelly/trunk/xdocs/style/project.css (added)
+++ jakarta/commons/proper/jelly/trunk/xdocs/style/project.css Sat Jun 2
15:59:58 2007
@@ -0,0 +1 @@
[EMAIL PROTECTED] url("http://jakarta.apache.org/style/jakarta-maven.css";);
\ No newline at end of file
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jexl] grammar for defining a map
On 6/2/07, peter royal <[EMAIL PROTECTED]> wrote: On Jun 1, 2007, at 10:09 PM, Dion Gillard wrote: > +1 done! see http://svn.apache.org/viewvc/jakarta/commons/proper/jexl/ trunk/src/test/org/apache/commons/jexl/MapLiteralTest.java? view=markup for example usage. Cool. Can you complete the related commit (see nightly build and gump nags). -Rahul -pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCXML] Forward eventdata within transition
On 6/1/07, Ingmar Kliche <[EMAIL PROTECTED]> wrote: Rahul, within a transition (which is gets eventdata from outside) I'd like to forward some pieces of the eventdata structure using a with namelist: As it does obviously not work it seems to me that the _eventdata structure is not accessible within a tags namelist. Is this intended? I think it would be helpful. As a work around I save the value temporarily to the data model using and use "temp" within the send tags namelist attribute. But it would be more convenient to access it directly. What do you think? Namelist is treated as a space-separated list of variable names (as it seems to imply). From your example, '_eventdata.eventValue' is an expression. So, its the difference between a 'get' and an 'evaluate' (which also explains why the 'temp' bit works). I think either the attribute should be renamed (by the WG) or spec should better clarify what each token is. Until then, I think we should be treating those as variable names, as we do now. -Rahul --Ingmar. PS: I'm using 0.7-SNAPSHOT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [functor] revival WAS Functor Users / Project Management?
On 5/30/07, Matt Benson <[EMAIL PROTECTED]> wrote: Right, I meant "whether the vote should be held" as in "are there any reasons why reviving [functor] would be simply out of the question?" I wasn't implying any desire to circumvent established protocols. :) Not sure if there is an established protocol :-) (other than that bit on the site, since dormancy has sort of been a one-way street -- I'm for voting). -Rahul -Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [functor] revival WAS Functor Users / Project Management?
On 5/30/07, Matt Benson <[EMAIL PROTECTED]> wrote: Hi Pete-- I could be interested in being the Jakarta commons conduit for a revival of the functor code. According to the jakarta website, "A revival of a Commons Dormant component must be preceded by a VOTE on the commons developers mailing list." Is there a general feeling on-list as to whether the vote should be held, I think its good to have the vote as suggested (after any preliminary discussion here). While its a lower bar than sandbox graduation, I think its useful to gauge interest and makes it harder for the change to slip under people's radar etc. As an aside, I do not have any cycles to help with functor ATM. -Rahul or any thoughts on why the revival of [functor] would be ill-advised? -Matt --- Pete Aykroyd <[EMAIL PROTECTED]> wrote: > Hi all, > > I'm not really sure how this is done but over the > past year and a half > or so, I've been working one of the original functor > contributors, > Jason Horman, on a branch of functor and we've made > a lot of progress > with it. For example, it's updated to take advantage > of generics which > is extremely helpful and also have done a lot work > developing > compilers that allows you to translate expressions > into runtime > functions, etc. This has been extremely useful for > us on our project > and we'd like to get this code back into the main > branch. > > I've emailed Rodney Waldhoff, who is listed as the > project lead for > functor but haven't heard back. There's been no > progress on functor > since 2005 and I don't want to step on toes, but I'm > also interested > in contributing to the community. > > Any pointers on what can be done would be > appreciated. > > Thanks, > > Pete > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-parent 3 (take 2)
On 5/30/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: This is the second attempt to release version 3 of commons-parent. The revision to vote on is 542829. [X] +1 [ ] =0 [ ] -1 -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (SCXML-45) Payload of events sent to current scxml session using tag not injected into engine
[ https://issues.apache.org/jira/browse/SCXML-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Akolkar resolved SCXML-45. Resolution: Fixed Fix Version/s: 0.7 Copying the commit message from r542582: This has been implemented (with a test case), however note the following caveat -- The spec doesn't clarify how multiple elements that create derived events should be handled, so for example: I think they should be processed together (this makes sense to leverage parallel regions for example), and due to that '_eventdata' becomes ambiguous in this scenario. The Commons SCXML implementation introduces an implicit variable '_eventdatamap' for such scenarios wherein the event datas are stored keyed by event name. So, the two events above could be processed by two regions like so: To summarize, the _eventdatamap variable needs to be used in association with "derived" (such as being discussed here) events. Also note that this behavior may change if there is clarity in the specification at some point. > Payload of events sent to current scxml session using tag not injected > into engine > - > > Key: SCXML-45 > URL: https://issues.apache.org/jira/browse/SCXML-45 > Project: Commons SCXML > Issue Type: Bug >Affects Versions: 0.6 >Reporter: Ingmar Kliche >Assignee: Rahul Akolkar >Priority: Minor > Fix For: 0.7 > > > Events which are sent to the current scxml session using the tag (i.e. > target = empty) may contain payload specified by the namelist attribute. This > payload is currently not fed back into engine when the event is created. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r542582 - in /jakarta/commons/proper/scxml/trunk/src: main/java/org/apache/commons/scxml/ main/java/org/apache/commons/scxml/model/ test/java/org/apache/commons/scxml/ test/java/org/apache
Author: rahul
Date: Tue May 29 09:31:02 2007
New Revision: 542582
URL: http://svn.apache.org/viewvc?view=rev&rev=542582
Log:
SCXML-45
Payload of events sent to current scxml session using tag not injected
into engine
This has been implemented (with a test case), however note the following caveat
--
The spec doesn't clarify how multiple elements that create derived
events should be handled, so for example:
I think they should be processed together (this makes sense to leverage
parallel regions for example), and due to that '_eventdata' becomes ambiguous
in this scenario. The Commons SCXML implementation introduces an implicit
variable '_eventdatamap' for such scenarios wherein the event datas are stored
keyed by event name.
So, the two events above could be processed by two regions like so:
To summarize, the _eventdatamap variable needs to be used in association with
"derived" (such as being discussed here) events. Also note that this
behavior may change if there is clarity in the specification at some point.
Added:
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/jexl/eventdata-03.xml
(with props)
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLExecutor.java
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/model/Send.java
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/EventDataTest.java
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLExecutor.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLExecutor.java?view=diff&rev=542582&r1=542581&r2=542582
==
---
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLExecutor.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLExecutor.java
Tue May 29 09:31:02 2007
@@ -536,6 +536,8 @@
currentStatus = step.getAfterStatus();
scInstance.getRootContext().setLocal("_ALL_STATES",
SCXMLHelper.getAncestorClosure(currentStatus.getStates(), null));
+setEventData((TriggerEvent[]) currentStatus.getEvents().
+toArray(new TriggerEvent[0]));
}
/**
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/model/Send.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/model/Send.java?view=diff&rev=542582&r1=542581&r2=542582
==
---
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/model/Send.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/model/Send.java
Tue May 29 09:31:02 2007
@@ -328,7 +328,7 @@
+ "' with no delay");
}
derivedEvents.add(new TriggerEvent(event,
-TriggerEvent.SIGNAL_EVENT));
+TriggerEvent.SIGNAL_EVENT, params));
return;
}
} else {
Modified:
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/EventDataTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/EventDataTest.java?view=diff&rev=542582&r1=542581&r2=542582
==
---
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/EventDataTest.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/EventDataTest.java
Tue May 29 09:31:02 2007
@@ -45,7 +45,7 @@
}
// Test data
-private URL eventdata01, eventdata02;
+private URL eventdata01, eventdata02, eventdata03;
private SCXMLExecutor exec;
/**
@@ -56,13 +56,15 @@
getResource("org/apache/commons/scxml/env/jexl/eventdata-01.xml");
eventdata02 = this.getClass().getClassLoader().
getResource("org/apache/commons/scxml/env/jexl/eventdata-02.xml");
+eventdata03 = this.getClass().getClassLoader().
+getResource("org/apache/commons/scxml/env/jexl/eventdata-03.xml");
}
/**
* Tear down instance variables required by this test case.
*/
public void tearDown() {
-eventdata01 = eventdata02 = null;
+eventdata01 = eventdata02 = eventdata03 = null;
}
/**
@@ -120,6 +122,25 @@
currentStates = SCXMLTestHelper.fireEvent(exec, te2);
Re: [VOTE] Release commons-parent 3
On 5/18/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: Hi, I'd like to push out version 3 of the commons-parent project. The changes in maven-sources-plugin 2.0.3 allow to get rid of the maven-antrun hack and that's reason enough, IMO. [X] +1 [ ] =0 [ ] -1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCXML] sending internal events using with payload
On 5/28/07, Ingmar Kliche <[EMAIL PROTECTED]> wrote: Rahul, the tag may be used to send events to external systems or to raise (external) events within the current SCXML session. I'm trying to structure my SCXML document into logically and hierarchically separated state machines (within one document, i.e. without invoking an external SCXML state machine!) using the parallel construct. I'd like to send events between the different parts using the tag including event payload ( i.e. namelist attribute). But as far as I understand the current implementation of (execute() in ..scxml/model/Send.java) a given payload (namelist) will not be attached to the TriggerEvent() which is feeded back into the state machine. Is this intended? I do not understand the spec in this way that events which are injected into the current session may not carry a payload. What do you think? I agree. I think in this scenario, the payload should be a map with the variable name value pairs (from the namelist). I'll fix this in a couple of days when I get a chance, if you want you can open an issue to track this [1]. -Rahul [1] http://jakarta.apache.org/commons/scxml/issue-tracking.html Regards, Ingmar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCXML] Bug on decision of transition?
On 5/25/07, Ingmar Kliche <[EMAIL PROTECTED]> wrote: I noticed that commons-scxml executes multiple transitions on one event as soon as multiple transitions (i.e. multiple transitions exist for one event) match. The SCXML spec instead says that only one transition has to be taken (the first in document order) as long as it is not a parallel construct. I suspect you're using v0.6. Recent changes now take into account document order. In fact, here is a similar test case: http://svn.apache.org/repos/asf/jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/tie-breaker-01.xml Please try building [1] from trunk [2]. -Rahul [1] http://jakarta.apache.org/commons/scxml/building.html [2] http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/ To illustrate this behavior I modified the state chart of the stop watch example to http://www.w3.org/2005/07/scxml"; version="1.0" initialstate="init"> ... * * I.e. the reset state contains two transitions for the event "watch.start". According to the SCXML spec I would assume that the first transition in document order will be taken, but commons-scxml executes both transitions and ends up in two states. See the following log: 25.05.2007 16:27:01 org.apache.commons.scxml.env.SimpleErrorReporter onError WARNUNG: NON_DETERMINISTIC (Multiple conflicting transitions enabled.): [transition (event = watch.start, cond = null, from = /reset, to = /stopped), transition (event = watch.start, cond = null, from = /reset, to = /running)] 25.05.2007 16:27:01 org.apache.commons.scxml.env.SimpleErrorReporter onError WARNUNG: ILLEGAL_CONFIG (Multiple top-level OR states active!): : [/running, /stopped] 25.05.2007 16:27:01 org.apache.commons.scxml.env.SimpleErrorReporter onError WARNUNG: ILLEGAL_CONFIG (Multiple top-level OR states active!): : [/running, /stopped] 25.05.2007 16:27:01 org.apache.commons.scxml.SCXMLExecutor logState INFO: Current States: [running, stopped] Is this behaviour inteted? Thanks and regards, Ingmar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 2nd attempt: Release commons-io 1.3.2
On 5/18/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: On 5/18/07, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > Was there a response to my comment [1] about r518770? Sorry, I wasn't reading your comment. But, to be honest, I have to admit that after reading it, I do not understand what you propose as a better solution? I'm proposing to declare the FileCleaningTracker in DiskFileItem to be transient. FileCleaningTracker is currently returning a brand new instance after a round trip (its not really being serialized, it shouldn't be declared Serializable IMO). I'm away this weekend, and probably won't be able to respond further till Monday, sorry about that. -Rahul Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 2nd attempt: Release commons-io 1.3.2
Was there a response to my comment [1] about r518770? -Rahul (long, possibly fragmented URL below) [1] http://www.nabble.com/Re%3A--io--fileupload--svn-commit%3A-r518770---in--jakarta-commons-proper-io-trunk-src%3A-java-org-apache-commons-io-FileCleaningTracker.java-test-org-apache-commons-io-FileUtilsCleanDirectoryTestCase.java-p9520876.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IO] Move to a minimum of JDK 1.4?
On 5/15/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: There are a couple of Jira tickets which require JDK 1.4 IO-74[1] - Regular Expression IOFileFilter implementation IO-77[2] - FileUtils.move() method that uses NIO Are there any objections to moving Commons IO's minimum requirement to JDK 1.4 for Commons IO 1.4? Sounds good. I've read the rest of the thread -- probably good to branch regardless of whether both lines are under active (evolutionary, in my mind) development or not. If someone shows up with desire to do a point / bugfix release for JDK 1.3 etc. -Rahul Niall [1] https://issues.apache.org/jira/browse/IO-74 [2] https://issues.apache.org/jira/browse/IO-77 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] commons collection classes
On 5/18/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: Having said that - the current situation has been in place for over 2 years and there haven't been complaints until now. Yup, and I don't perceive any urgency here (not that I'd want us to recommend this again). -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCXML] Feb '07 WD support
On 4/27/07, Ingmar Kliche <[EMAIL PROTECTED]> wrote: Rahul, nice to see that you are already working on the Feb '07 WD support. We really appreciate this! Thank you for your effort! How far are these changes? Most of the "structural" changes for the core state machine bits are done, for example, compare before [1] and after [2]. [1] http://svn.apache.org/repos/asf/jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/jexl/microwave-02.xml [2] http://svn.apache.org/repos/asf/jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/env/jexl/microwave-04.xml I do not intend to cover s and rollback in the next minor release (v0.7 -- since support is optional, and I don't think its completely fleshed out ATM). There might be other odds and ends to be taken care of, I'll be doing another scan of the latest WD for that. Do you plan to build a new release (e.g. 0.7) or do I need to check out from SVN to get the Feb '07 support? A v0.7 would be good after these changes IMO, but its for the Commons community to decide (I can propose the release). Thats probably going to take a couple of months given that I'll be out of the country for the next three weeks. For now, please build [3] from trunk [4]. All feedback about the trunk is welcome. [3] http://jakarta.apache.org/commons/scxml/building.html [4] http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/ Currently I use rel v0.6 and I'd like to stay as close as possible with the W3C standard development. Are you going to send out some announcement once Feb '07 WD support is complete? I wasn't planning on sending out such a note, but I might now. -Rahul Thanks again and regards, Ingmar 2007/4/25, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > > Author: rahul > Date: Wed Apr 25 13:50:29 2007 > New Revision: 532478 > > URL: http://svn.apache.org/viewvc?view=rev&rev=532478 > Log: > Feb '07 WD conformance changes for the IO package: > - Update parser to support , changed usage of > - Make static nested classes private > - Add a Commons SCXML namespace to support implementation specific actions > - Eliminate use of deprecated APIs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r532488 - /jakarta/commons/proper/scxml/trunk/xdocs/usecases/scxml-stopwatch/
Author: rahul Date: Wed Apr 25 14:11:39 2007 New Revision: 532488 URL: http://svn.apache.org/viewvc?view=rev&rev=532488 Log: svn:ignore Modified: jakarta/commons/proper/scxml/trunk/xdocs/usecases/scxml-stopwatch/ (props changed) Propchange: jakarta/commons/proper/scxml/trunk/xdocs/usecases/scxml-stopwatch/ -- --- svn:ignore (added) +++ svn:ignore Wed Apr 25 14:11:39 2007 @@ -0,0 +1 @@ +Thumbs.db - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r532486 - in /jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml: ./ io/ semantics/
Author: rahul
Date: Wed Apr 25 14:06:11 2007
New Revision: 532486
URL: http://svn.apache.org/viewvc?view=rev&rev=532486
Log:
JUnit test cases update:
- Remove deprecated API usage
- Wire up the tests added in r522070 for the new parser
Modified:
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLExecutorTest.java
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLHelperTest.java
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/io/IOTestSuite.java
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/io/SCXMLDigesterTest.java
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/io/SCXMLSerializerTest.java
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/semantics/TransitionTargetComparatorTest.java
Modified:
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLExecutorTest.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLExecutorTest.java?view=diff&rev=532486&r1=532485&r2=532486
==
---
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLExecutorTest.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/SCXMLExecutorTest.java
Wed Apr 25 14:06:11 2007
@@ -28,6 +28,7 @@
import org.apache.commons.scxml.env.SimpleContext;
import org.apache.commons.scxml.env.jsp.ELEvaluator;
+import org.apache.commons.scxml.model.SCXML;
import org.apache.commons.scxml.model.State;
import org.apache.commons.scxml.model.TransitionTarget;
/**
@@ -50,8 +51,8 @@
// Test data
private URL microwave01jsp, microwave02jsp, microwave01jexl,
-microwave02jexl, transitions01, transitions02, transitions03,
-prefix01, send01, send02;
+microwave02jexl, microwave03jexl, microwave04jexl, transitions01,
+transitions02, transitions03, transitions04, prefix01, send01, send02;
private SCXMLExecutor exec;
/**
@@ -66,12 +67,18 @@
getResource("org/apache/commons/scxml/env/jexl/microwave-01.xml");
microwave02jexl = this.getClass().getClassLoader().
getResource("org/apache/commons/scxml/env/jexl/microwave-02.xml");
+microwave03jexl = this.getClass().getClassLoader().
+getResource("org/apache/commons/scxml/env/jexl/microwave-03.xml");
+microwave04jexl = this.getClass().getClassLoader().
+getResource("org/apache/commons/scxml/env/jexl/microwave-04.xml");
transitions01 = this.getClass().getClassLoader().
getResource("org/apache/commons/scxml/transitions-01.xml");
transitions02 = this.getClass().getClassLoader().
getResource("org/apache/commons/scxml/transitions-02.xml");
transitions03 = this.getClass().getClassLoader().
getResource("org/apache/commons/scxml/transitions-03.xml");
+transitions04 = this.getClass().getClassLoader().
+getResource("org/apache/commons/scxml/transitions-04.xml");
prefix01 = this.getClass().getClassLoader().
getResource("org/apache/commons/scxml/prefix-01.xml");
send01 = this.getClass().getClassLoader().
@@ -85,8 +92,8 @@
*/
public void tearDown() {
microwave01jsp = microwave02jsp = microwave01jexl = microwave02jexl =
-transitions01 = transitions02 = transitions03 = prefix01 =
-send01 = send02 = null;
+microwave04jexl = transitions01 = transitions02 = transitions03 =
+transitions04 = prefix01 = send01 = send02 = null;
}
/**
@@ -118,6 +125,24 @@
checkMicrowave02Sample();
}
+// Uses SCXMLParser (latest WD)
+public void testSCXMLExecutorMicrowave03JexlSample() {
+SCXML scxml = SCXMLTestHelper.parse(microwave03jexl);
+assertNotNull(scxml);
+exec = SCXMLTestHelper.getExecutor(scxml);
+assertNotNull(exec);
+checkMicrowave01Sample();
+}
+
+// Uses SCXMLParser (latest WD)
+public void testSCXMLExecutorMicrowave04JexlSample() {
+SCXML scxml = SCXMLTestHelper.parse(microwave04jexl);
+assertNotNull(scxml);
+exec = SCXMLTestHelper.getExecutor(scxml);
+assertNotNull(exec);
+checkMicrowave02Sample();
+}
+
public void testSCXMLExecutorPrefix01Sample() {
exec = SCXMLTestHelper.getExecutor(prefix01);
assertNotNull(exec);
@@ -193,6 +218,36 @@
fail(e.getMessage());
}
}
+
+// Uses SCXMLParser (latest WD)
+public void testSCXMLExecutorTransitions04Sample() {
+SCXML scxml = SCXMLTestHelper.parse(transitions04);
+
svn commit: r532485 - /jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/test/StandaloneUtils.java
Author: rahul
Date: Wed Apr 25 14:00:45 2007
New Revision: 532485
URL: http://svn.apache.org/viewvc?view=rev&rev=532485
Log:
Switch the test package to use new parser.
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/test/StandaloneUtils.java
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/test/StandaloneUtils.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/test/StandaloneUtils.java?view=diff&rev=532485&r1=532484&r2=532485
==
---
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/test/StandaloneUtils.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/test/StandaloneUtils.java
Wed Apr 25 14:00:45 2007
@@ -32,7 +32,7 @@
import org.apache.commons.scxml.env.SimpleScheduler;
import org.apache.commons.scxml.env.Tracer;
import org.apache.commons.scxml.invoke.SimpleSCXMLInvoker;
-import org.apache.commons.scxml.io.SCXMLDigester;
+import org.apache.commons.scxml.io.SCXMLParser;
import org.apache.commons.scxml.io.SCXMLSerializer;
import org.apache.commons.scxml.model.ModelException;
import org.apache.commons.scxml.model.SCXML;
@@ -76,7 +76,7 @@
String documentURI = getCanonicalURI(uri);
Context rootCtx = evaluator.newContext(null);
Tracer trc = new Tracer();
-SCXML doc = SCXMLDigester.digest(new URL(documentURI), trc);
+SCXML doc = SCXMLParser.parse(new URL(documentURI), trc);
if (doc == null) {
System.err.println("The SCXML document " + uri
+ " can not be parsed!");
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r532482 - /jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLHelper.java
Author: rahul
Date: Wed Apr 25 13:53:01 2007
New Revision: 532482
URL: http://svn.apache.org/viewvc?view=rev&rev=532482
Log:
Remove deprecated API usage.
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLHelper.java
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLHelper.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLHelper.java?view=diff&rev=532482&r1=532481&r2=532482
==
---
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLHelper.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/SCXMLHelper.java
Wed Apr 25 13:53:01 2007
@@ -152,7 +152,7 @@
Set count = (Set) entry.getValue();
if (tt instanceof Parallel) {
Parallel p = (Parallel) tt;
-if (count.size() < p.getStates().size()) {
+if (count.size() < p.getChildren().size()) {
errRep.onError(ErrorConstants.ILLEGAL_CONFIG,
"Not all AND states active for parallel "
+ p.getId(), entry);
@@ -249,7 +249,7 @@
Parallel par = ((Parallel) ((State) regions.next()).
getParent());
//let's find affected states in sibling regions
-for (Iterator siblings = par.getStates().iterator();
+for (Iterator siblings = par.getChildren().iterator();
siblings.hasNext();) {
State s = (State) siblings.next();
for (Iterator act = currentStates.iterator();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r532480 - in /jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics: SCXMLSemanticsImpl.java TransitionTargetComparator.java
Author: rahul
Date: Wed Apr 25 13:52:18 2007
New Revision: 532480
URL: http://svn.apache.org/viewvc?view=rev&rev=532480
Log:
Feb '07 WD related minor tweaks for the semantics package, mostly:
- Eliminate use of deprecated APIs
- Better naming as a consequence of above
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/TransitionTargetComparator.java
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java?view=diff&rev=532480&r1=532479&r2=532480
==
---
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/SCXMLSemanticsImpl.java
Wed Apr 25 13:52:18 2007
@@ -109,8 +109,8 @@
/**
* @param input
*SCXML state machine [in]
- * @param states
- *a set of States to populate [out]
+ * @param targets
+ *a set of initial targets to populate [out]
* @param entryList
*a list of States and Parallels to enter [out]
* @param errRep
@@ -120,19 +120,19 @@
* @throws ModelException
* in case there is a fatal SCXML object model problem.
*/
-public void determineInitialStates(final SCXML input, final Set states,
+public void determineInitialStates(final SCXML input, final Set targets,
final List entryList, final ErrorReporter errRep,
final SCInstance scInstance)
throws ModelException {
-State tmp = input.getInitialState();
+TransitionTarget tmp = input.getInitialTarget();
if (tmp == null) {
errRep.onError(ErrorConstants.NO_INITIAL,
"SCXML initialstate is missing!", input);
} else {
-states.add(tmp);
-determineTargetStates(states, errRep, scInstance);
+targets.add(tmp);
+determineTargetStates(targets, errRep, scInstance);
//set of ALL entered states (even if initialState is a jump-over)
-Set onEntry = SCXMLHelper.getAncestorClosure(states, null);
+Set onEntry = SCXMLHelper.getAncestorClosure(targets, null);
// sort onEntry according state hierarchy
Object[] oen = onEntry.toArray();
onEntry.clear();
@@ -261,8 +261,8 @@
//let's check its siblings too
Parallel p = (Parallel) parent.getParent();
int finCount = 0;
-int pCount = p.getStates().size();
-for (Iterator regions = p.getStates().iterator();
+int pCount = p.getChildren().size();
+for (Iterator regions = p.getChildren().iterator();
regions.hasNext();) {
State reg = (State) regions.next();
if (reg.isDone()) {
@@ -505,7 +505,7 @@
for (Iterator k = regs.iterator(); k.hasNext();) {
State region = (State) k.next();
regions.addAll(((Parallel) region.getParent()).
-getStates());
+getChildren());
}
}
}
@@ -548,7 +548,7 @@
// NOTE: Digester has to verify this precondition!
if (st.isSimple()) {
states.add(st); //leaf
-} else if (st.isOrthogonal()) {
+} else if (st.isOrthogonal()) { //TODO: Remove else if in v1.0
wrkSet.addLast(st.getParallel()); //parallel
} else {
// composite state
@@ -558,7 +558,7 @@
}
} else if (tt instanceof Parallel) {
Parallel prl = (Parallel) tt;
-for (Iterator i = prl.getStates().iterator(); i.hasNext();) {
+for (Iterator i = prl.getChildren().iterator(); i.hasNext();) {
//fork
wrkSet.addLast(i.next());
}
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/TransitionTargetComparator.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/TransitionTargetComparator.java?view
svn commit: r532478 - in /jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io: ModelUpdater.java SCXMLParser.java SCXMLSerializer.java
Author: rahul
Date: Wed Apr 25 13:50:29 2007
New Revision: 532478
URL: http://svn.apache.org/viewvc?view=rev&rev=532478
Log:
Feb '07 WD conformance changes for the IO package:
- Update parser to support , changed usage of
- Make static nested classes private
- Add a Commons SCXML namespace to support implementation specific actions
- Eliminate use of deprecated APIs
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/ModelUpdater.java
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLParser.java
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLSerializer.java
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/ModelUpdater.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/ModelUpdater.java?view=diff&rev=532478&r1=532477&r2=532478
==
---
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/ModelUpdater.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/ModelUpdater.java
Wed Apr 25 13:50:29 2007
@@ -61,21 +61,24 @@
String initialstate = scxml.getInitialstate();
//we have to use getTargets() here since the initialState can be
//an indirect descendant
- // Concern marked by one of the code reviewers: better type check,
- //now ClassCastException happens for Parallel
- // Response: initial should be a State, for Parallel, it is implicit
- State initialState = (State) scxml.getTargets().get(initialstate);
- if (initialState == null) {
+ TransitionTarget initialTarget = (TransitionTarget) scxml.getTargets().
+ get(initialstate);
+ if (initialTarget == null) {
// Where do we, where do we go?
logAndThrowModelError(ERR_SCXML_NO_INIT, new Object[] {
initialstate });
}
- scxml.setInitialState(initialState);
+ scxml.setInitialTarget(initialTarget);
Map targets = scxml.getTargets();
- Map states = scxml.getStates();
- Iterator i = states.keySet().iterator();
+ Map children = scxml.getChildren();
+ Iterator i = children.keySet().iterator();
while (i.hasNext()) {
- updateState((State) states.get(i.next()), targets);
+ TransitionTarget tt = (TransitionTarget) children.get(i.next());
+ if (tt instanceof State) {
+ updateState((State) tt, targets);
+ } else {
+ updateParallel((Parallel) tt, targets);
+ }
}
}
@@ -170,7 +173,7 @@
Transition trn = (Transition) t.get(i);
updateTransition(trn, targets);
}
-Parallel p = s.getParallel();
+Parallel p = s.getParallel(); //TODO: Remove in v1.0
Invoke inv = s.getInvoke();
if ((inv != null && p != null)
|| (inv != null && !c.isEmpty())
@@ -216,7 +219,7 @@
*/
private static void updateParallel(final Parallel p, final Map targets)
throws ModelException {
-Iterator i = p.getStates().iterator();
+Iterator i = p.getChildren().iterator();
while (i.hasNext()) {
updateState((State) i.next(), targets);
}
@@ -322,7 +325,7 @@
return false; // One per region
}
}
-if (regions.size() != p.getStates().size()) {
+if (regions.size() != p.getChildren().size()) {
return false; // Must represent all regions
}
return true;
Modified:
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLParser.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLParser.java?view=diff&rev=532478&r1=532477&r2=532478
==
---
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLParser.java
(original)
+++
jakarta/commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/io/SCXMLParser.java
Wed Apr 25 13:50:29 2007
@@ -34,7 +34,6 @@
import org.apache.commons.digester.SetNextRule;
import org.apache.commons.digester.SetPropertiesRule;
import org.apache.commons.logging.LogFactory;
-
import org.apache.commons.scxml.PathResolver;
import org.apache.commons.scxml.SCXMLHelper;
import org.apache.commons.scxml.env.URLResolver;
@@ -49,6 +48,7 @@
import org.apache.commons.scxml.model.Executable;
import org.apache.commons.scxml.model.Exit;
import org.apache.commons.scxml.model.ExternalContent;
+import org.apache.commons.scxml.model.Final;
import org.apache.commons.scxml.model.Finalize;
impor
Re: [beansutils] v1.7.1
On 4/25/07, maestro <[EMAIL PROTECTED]> wrote: Hi, I have tried to locate some information on how to obtain the latest source for v1.7.1 and build it. I found information on how to build it... but nothing on how to get the source. :( Can anyone help me? svn co http://svn.apache.org/repos/asf/jakarta/commons/proper/beanutils/trunk (you'll need a SVN client) It appears there is no plan for a v1.7.1 any time soon. -Rahul - maestro - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (SANDBOX-185) [exec] setWatchDog method in DefaultExecutor has no affect
[ https://issues.apache.org/jira/browse/SANDBOX-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Akolkar resolved SANDBOX-185. --- Resolution: Fixed Fixed by sgoeschl in r518598 [1]. [1] http://svn.apache.org/viewvc?view=rev&revision=518598 > [exec] setWatchDog method in DefaultExecutor has no affect > -- > > Key: SANDBOX-185 > URL: https://issues.apache.org/jira/browse/SANDBOX-185 > Project: Commons Sandbox > Issue Type: Bug > Components: Exec > Environment: All Environments >Reporter: Bindul Bhowmik > Attachments: default-executor.patch > > > The setWatchDog method in org.apache.commons.exec.DefaultExecutor.java does > not have any affect due to a case discrepancy. The method parameter for the > method is watchDog and the value that is assigned is watchdog (the same as > the class field). > I have attached a patch for the same. If required I could add in a test case > for this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r529805 - in /jakarta/commons/proper/jci/trunk/src/site: site.xml xdoc/faq.xml
On 4/23/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Rahul Akolkar wrote: > On 4/23/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: >> [EMAIL PROTECTED] wrote: >> > Author: tcurdt >> > Date: Tue Apr 17 16:46:08 2007 >> > New Revision: 529805 >> > >> > URL: http://svn.apache.org/viewvc?view=rev&rev=529805 >> > Log: >> > rephrased a few o=paragraphs, >> > fixed broken links >> > >> >> This should not be necessary. If you use full URLs like this, you won't >> be able to navigate a locally built site correctly. What kind of >> problems did you run into? You stated "broken links" as the reason for >> the change in the commit message. >> > > > Apparently, the site.xml "inheritance" does not tweak relative URLs as > needed (and expected). > > -Rahul So, the sub modules of jci are getting menu links that doesn't work? Before, yes. -Rahul -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r529805 - in /jakarta/commons/proper/jci/trunk/src/site: site.xml xdoc/faq.xml
On 4/23/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote: > Author: tcurdt > Date: Tue Apr 17 16:46:08 2007 > New Revision: 529805 > > URL: http://svn.apache.org/viewvc?view=rev&rev=529805 > Log: > rephrased a few o=paragraphs, > fixed broken links > > > Modified: > jakarta/commons/proper/jci/trunk/src/site/site.xml > jakarta/commons/proper/jci/trunk/src/site/xdoc/faq.xml > > Modified: jakarta/commons/proper/jci/trunk/src/site/site.xml > URL: http://svn.apache.org/viewvc/jakarta/commons/proper/jci/trunk/src/site/site.xml?view=diff&rev=529805&r1=529804&r2=529805 > == > --- jakarta/commons/proper/jci/trunk/src/site/site.xml (original) > +++ jakarta/commons/proper/jci/trunk/src/site/site.xml Tue Apr 17 16:46:08 2007 > @@ -1,4 +1,4 @@ > - > + > > > Jakarta Commons JCI > @@ -7,10 +7,10 @@ > > > > - > - > - > - > +http://jakarta.apache.org/commons/jci/index.html"/> > +http://jakarta.apache.org/commons/jci/usage.html"/> > +http://jakarta.apache.org/commons/jci/faq.html"/> > +http://jakarta.apache.org/commons/jci/downloads.html"/> This should not be necessary. If you use full URLs like this, you won't be able to navigate a locally built site correctly. What kind of problems did you run into? You stated "broken links" as the reason for the change in the commit message. Apparently, the site.xml "inheritance" does not tweak relative URLs as needed (and expected). -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release commons jci RC1 as 1.0
On 4/17/07, Niall Pemberton <[EMAIL PROTECTED]> wrote: AIU projects using m2 that vote on actual release artifacts use a "staging" repository - but I guess that would take a change in the commons pom first. Anyway ignore my comment - I've not done a release using m2 and I guess if you resolve the reason why the release plugin didn't correctly update all the dependency versions for the RC then it should be OK. I'd prefer to vote on the actual artifacts, and FWIW, I'd mostly vote no better than +0 for anything else (ofcourse, this is not a JCI specific comment). -Rahul P.S.-Thanks for the license / notice additions to all modules. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SCXML-44) Interface consistency: State.getIsFinal and State.setIsFinal
[ https://issues.apache.org/jira/browse/SCXML-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Akolkar updated SCXML-44: --- Fix Version/s: 0.7 Lets aim to initiate a deprecate, replace and remove cycle starting v0.7. > Interface consistency: State.getIsFinal and State.setIsFinal > > > Key: SCXML-44 > URL: https://issues.apache.org/jira/browse/SCXML-44 > Project: Commons SCXML > Issue Type: Improvement >Affects Versions: 0.6 >Reporter: Jörg Weinmann >Priority: Trivial > Fix For: 0.7 > > > Getter and setter method for boolean isFinal is inconsistent to similiar > getter and setter methods in the class. > I would have expected: State.isFinal() and State.setFinal(). > Compare to isDone(), isSimple(), isDone(), setDone(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli-avalon] svn commit: r529044 - /jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml
On 4/15/07, sebb <[EMAIL PROTECTED]> wrote:
On 15/04/07, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> On 4/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Author: sebb
> > Date: Sun Apr 15 11:33:27 2007
> > New Revision: 529044
> >
> > URL: http://svn.apache.org/viewvc?view=rev&rev=529044
> > Log:
> > Create minimal POM
> >
> > Added:
> > jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml
(with props)
[...]
> Since this a new component, we should preferably discuss its creation
> (then have a vote if needed etc.).
Not sure I follow that - all I've done is create a Pom so it can be
built independently - the code has been in SVN for some while now,
waiting for someone to do a release (please!)
If we look at what defines a component in the maven sense, we are
talking about the {groupId,artifactId} tuple, which is new in the POM
you added (my comment was under the line, I should have
spelt that out instead). In terms of development in Commons, I think
of branches as potentially different lines of development of the same
component, rather than potentially different components.
For [cli], we've ended up with a divergent set of codebases and
releasing each is probably not making it better. Its confusing,
suboptimal, and hopefully, avoidable. If enough of us want to see more
than one cli-ish component released out of Commons, then IMO it would
be nice to (not in any temporal order):
* Treat this as component creation (rather than just another [cli]
release), and acceptance into Commons Proper is usually via a vote
* Have a [cli-avalon] site
* Have all cli-ish components' sites point to each other, explain why
there are more than one, why users should prefer one over the other
etc.
-Rahul
Sebb
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli-avalon] svn commit: r529044 - /jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml
On 4/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: sebb Date: Sun Apr 15 11:33:27 2007 New Revision: 529044 URL: http://svn.apache.org/viewvc?view=rev&rev=529044 Log: Create minimal POM Added: jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml (with props) Added: jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml?view=auto&rev=529044 == --- jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml (added) +++ jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml Sun Apr 15 11:33:27 2007 @@ -0,0 +1,95 @@ + + +http://maven.apache.org/POM/4.0.0"; +xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; +xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> + +org.apache.commons +commons-parent +1 + + 4.0.0 + commons-cli-avalon + commons-cli-avalon Since this a new component, we should preferably discuss its creation (then have a vote if needed etc.). -Rahul + 2.0-SNAPSHOT + CLI-Avalon + + 2002 + +Commons CLI (Avalon) provides a simple API for processing and +validating a command line interface. + + + http://jakarta.apache.org/commons/cli/ + + +jira +http://issues.apache.org/jira/browse/CLI + + + + scm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/cli/branches/avalon-implementation + scm:svn:https://svn.apache.org/repos/asf/jakarta/commons/proper/cli/branches/avalon-implementation + http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation + + + + + + + + junit + junit + 3.8.1 + test + + + + + jdepend + jdepend + 2.5 + test + + + + + +src/java +src/test + + + src/java/org/apache/commons/cli/avalon + org/apache/commons/cli/avalon + +**/*.properties + + + + . + META-INF + +NOTICE.txt +LICENSE.txt + + + + + + \ No newline at end of file Propchange: jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml -- svn:eol-style = native Propchange: jakarta/commons/proper/cli/branches/avalon-implementation/pom.xml -- svn:keywords = Author Date Id Revision - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cli-avalon] svn commit: r529017 - /jakarta/commons/proper/cli/branches/avalon-implementation/src/conf/MANIFEST.MF
On 4/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: sebb Date: Sun Apr 15 10:18:33 2007 New Revision: 529017 URL: http://svn.apache.org/viewvc?view=rev&rev=529017 Log: CLI2 -> Avalon Modified: jakarta/commons/proper/cli/branches/avalon-implementation/src/conf/MANIFEST.MF Modified: jakarta/commons/proper/cli/branches/avalon-implementation/src/conf/MANIFEST.MF URL: http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation/src/conf/MANIFEST.MF?view=diff&rev=529017&r1=529016&r2=529017 == Binary files - no diff available. Binary? -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r529008 - /jakarta/commons/trunks-sandbox/
Author: rahul Date: Sun Apr 15 09:52:45 2007 New Revision: 529008 URL: http://svn.apache.org/viewvc?view=rev&rev=529008 Log: Removing jci so trunks-sandbox checkout will not fail Modified: jakarta/commons/trunks-sandbox/ (props changed) Propchange: jakarta/commons/trunks-sandbox/ -- --- svn:externals (original) +++ svn:externals Sun Apr 15 09:52:45 2007 @@ -6,7 +6,6 @@ i18n https://svn.apache.org/repos/asf/jakarta/commons/sandbox/i18n/trunk id https://svn.apache.org/repos/asf/jakarta/commons/sandbox/id/trunk javaflow https://svn.apache.org/repos/asf/jakarta/commons/sandbox/javaflow/trunk -jci https://svn.apache.org/repos/asf/jakarta/commons/sandbox/jci/trunk js2j https://svn.apache.org/repos/asf/jakarta/commons/sandbox/js2j/trunk openpgp https://svn.apache.org/repos/asf/jakarta/commons/sandbox/openpgp/trunk pipeline https://svn.apache.org/repos/asf/jakarta/commons/sandbox/pipeline/trunk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (SCXML-43) SCXML parallelism
[ https://issues.apache.org/jira/browse/SCXML-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Akolkar resolved SCXML-43. Resolution: Invalid Thanks for the details -- the SCXML document and state machine diagram. At first glance, it does not seem to be a problem with the Commons SCXML library. I will respond to your email on the user list (titled "SCXML error") in a few minutes. > SCXML parallelism > - > > Key: SCXML-43 > URL: https://issues.apache.org/jira/browse/SCXML-43 > Project: Commons SCXML > Issue Type: Task > Environment: Windows >Reporter: Premi John >Priority: Critical > Attachments: State_Machine_Diagram.bmp > > > Hi there, > We are trying to use SCXML for one of our use case where we have lots of > state transitions and event generated. I am having problem with having > multiple transitions defined within a state. I am attaching herewith the > state diagram and the SCXML that I have tried creating. Please give your > suggestions on where I am wrong in defining the SCXML. > Thanks > John > I am not able to attach the state diagram here and is there any forum where I > can send attachments. > > > http://www.w3.org/2005/07/scxml"; > xmlns:my="http://my.custom-actions.domain/CUSTOM"; version="1.0" > initialstate="testMain"> > > > > > > > > > > > > > > > > cond="_eventdata.slotAvailable=true" > > target="MSlotHeldState.aquireSlot" /> > > cond="_eventdata.slotavailable=true" > > target="MSlotLockedState.lockSlot"/> > > cond="!_eventdata.slotAvailable" > > target="MSlotQueuedState.queueSlot" /> > > > > > > > > target="MSlotCancelledState.freeSlot" /> > > > > > > > > > > > > target="MSlotFreedState.releaseSlot" /> > > > > > >event="SlotReadyToBeHeldEvent" target="MSlotHeldState.aquireSlot" /> > > > >/> > > > > > > > > > > > >
[jira] Resolved: (SCXML-42) SCXML exception
[ https://issues.apache.org/jira/browse/SCXML-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Akolkar resolved SCXML-42. Resolution: Invalid Please post questions to the user list first. Thanks. > SCXML exception > > > Key: SCXML-42 > URL: https://issues.apache.org/jira/browse/SCXML-42 > Project: Commons SCXML > Issue Type: Bug > Environment: Windows >Reporter: Premi John >Priority: Blocker > > Hi there, > While implementing the parallelism in SCXML we are encountering an exception > which I am attaching herewith. Is there any work around for this. > 2007-04-12 11:52:44,922 INFO [scxml.app.log] null: Slot Init State > 2007-04-12 11:52:44,922 INFO [scxml.app.log] null: Task Init State > 2007-04-12 11:52:44,954 DEBUG [mdb] SQL Query - select > T_Schedule.SCH_ID,SCH_TYPE,SCH_KIND,SCH_USER, > SCH_PRIORITY,SCH_NAME,SCH_CRON,SCH_DISABLE,SCH_RELID,SCH_PARENTID,SCH_AB > ORT_INFO,SCH_TIME_POLICY,SCH_KIND,SCH_SUB_TYPE,SLOT_ID,RESID > ,RESTYPE,SLOT_FROM_TIME , SLOT_TO_TIME,SLOT_CAPACITY , > SLOT_STATE,aTask.TASK_ID ,aTask.IRESID,aTask.LRESID ,aTask.TASK_OPKID , > aTask.TASK_OPKTYPE , aTask.TASK_JOBCMDSTR ,aTask.TASK_DELTA ,aTask.TASK_STATE > , bTask.TASK_ID ,bTask.IRESID,bTask.LRESID ,bTask.TASK_OPKID , > bTask.TASK_OPKTYPE , bTask.TASK_JOBCMDSTR ,bTask.TASK_DELTA > ,bTask.TASK_STATE,aTask.TASK_TIME,bTask.TASK_TIME from > T_schedule,T_SLOT,T_TASK aTask,T_TASK bTASK where T_Schedule.SCH_ID=? > and T_Schedule.SCH_ID=T_SLOT.SCH_ID and T_SCHEDULE.SCH_ID=aTASK.SCH_ID and > T_SCHEDULE.SCH_ID=bTASK.SCH_ID and aTASK.TASK_ID != bTASK.TASK_ID group by > t_schedule.sch_id > 2007-04-12 11:52:44,954 INFO [STDOUT] MSlotTaskFSM :AQUIRE inside > MSlotTaskFSM of aTask: > 2007-04-12 11:52:44,954 INFO [STDOUT] MSlotTaskFSM :RELEASE inside > MSlotTaskFSM of bTask: > 2007-04-12 11:52:44,954 INFO [STDOUT] Inside ProcessEvent :Schedule Id is > :11:506 > 2007-04-12 11:52:45,109 WARN > [org.apache.commons.scxml.env.SimpleErrorReporter] NON_DETERMINISTIC > (Multiple conflicting transitions enabled.): [transition (event = > CreateATaskEvent, cond = _eventdata.slotAvailable=true, from = > /testMain/null/slotState/MSlotInitState, to = > /testMain/null/slotState/MSlotHeldState.aquireSlot), transition (event = > CreateATaskEvent, cond = !_eventdata.slotAvailable, from = > /testMain/null/slotState/MSlotInitState, to = > /testMain/null/slotState/MSlotQueuedState.queueSlot), transition (event = > CreateATaskEvent, cond = _eventdata.slotavailable=true, from = > /testMain/null/slotState/MSlotInitState, to = > /testMain/null/slotState/MSlotLockedState.lockSlot)] > 2007-04-12 11:52:45,109 WARN > [org.apache.commons.scxml.env.SimpleErrorReporter] ILLEGAL_CONFIG (Multiple > OR states active for state slotState): > /testMain/null/slotState : > [/testMain/null/slotState/MSlotHeldState.aquireSlot, > /testMain/null/slotState/MSlotQueuedState.queueSlot, > /testMain/null/slotState/MSlotLockedState.lockSlot] > 2007-04-12 11:52:45,109 ERROR [com.hp.m.msched.core.MSlotTaskFSM] > Illegal state machine configuration! > org.apache.commons.scxml.model.ModelException: Illegal state machine > configuration! > at > org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.followTransitions( > SCXMLSemanticsImpl.java:695) > at > org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java: > 127) > at > org.apache.commons.scxml.SCXMLExecutor.triggerEvent(SCXMLExecutor.java:1 > 60) > at > com.hp.m.msched.core.MSlotTaskFSM.fireEvent(MSlotTaskFSM.java:151) > at > com.hp.m.msched.core.MScheduleController.processEvent(MScheduleControlle > r.java:71) > at > com.hp.m.msched.core.MScheduleResourceController.processMessage(MSchedul > eResourceController.java:171) > at > com.hp.m.msched.mmsg.MSchedSCNMessageHandler.processMessage(MSchedSCNMes > sageHandler.java:38) > at com.hp.m.mmsg.jms.mdb.MDB.onMessage(MDB.java:49) > at com.hp.m.mmsg.jms.mdb.MSchedMDB.onMessage(MSchedMDB.java:9) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav > a:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor > Impl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at > org.jboss.invocation.Invocation.performCall(Invocation.java:359) > at > org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(Message > DrivenContainer.java:495) > at > org.jboss.resource.connectio
Re: [vote] release commons jci RC1 as 1.0
On 4/10/07, Torsten Curdt <[EMAIL PROTECTED]> wrote: Since RC1 is working fine for cocoon and other parties I would like to call a vote on the release for commons jci. http://jakarta.apache.org/commons/jci/ The site menus on all of the module sites seem broken (numerous 404s). While its a cosmetic issue, it does make it hard to go through the site documentation. http://people.apache.org/repo/m2-snapshot-repository/org/apache/ commons/commons-jci/1.0-RC1/ http://people.apache.org/repo/m2-snapshot-repository/org/apache/ commons/commons-jci-core/1.0-RC1/ No license and notice in above (core) jars. Stopped checking there. I will try to help with some of this, if needed, but can't this week. -Rahul http://people.apache.org/repo/m2-snapshot-repository/org/apache/ commons/commons-jci-eclipse/1.0-RC1/ http://people.apache.org/repo/m2-snapshot-repository/org/apache/ commons/commons-jci-fam/1.0-RC1/ http://people.apache.org/repo/m2-snapshot-repository/org/apache/ commons/commons-jci-groovy/1.0-RC1/ http://people.apache.org/repo/m2-snapshot-repository/org/apache/ commons/commons-jci-janino/1.0-RC1/ http://people.apache.org/repo/m2-snapshot-repository/org/apache/ commons/commons-jci-javac/1.0-RC1/ http://people.apache.org/repo/m2-snapshot-repository/org/apache/ commons/commons-jci-rhino/1.0-RC1/ Please cast your votes. cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
