[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=revrev=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 snip/ It seems no props were added. -Rahul - 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: snip/ 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. snap/ 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]
Re: [nightly build] dbcp failed.
On 7/24/07, Dain Sundstrom [EMAIL PROTECTED] wrote: Can anyone else reproduce this failure? snip/ 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: 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). snip/ 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]
[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]
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 snip/ 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. snap/ 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: 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 paste 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 /paste - 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. scxml xmlns=http://www.w3.org/2005/07/scxml version=1.0 initialstate=state1 state id=state1 onentry send event=foo/ /onentry transition event=foo target=state2 / /state state id=state2 final=true / /scxml -- 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: [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=revrev=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]
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. snip/ 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 . snap/ 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. snip/ 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. snap/ Agreed, note the current modus operandi sort of helps with that too. Other than that, I believe in as open a door as possible. snip/ 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: 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 snip/ 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: [VOTE] Release CLI 1.1 (3rd RC)
On 7/4/07, Henri Yandell [EMAIL PROTECTED] wrote: snip/ [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 snap/ 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: [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). snip/ 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). snap/ Sure, that makes sense. -Rahul Phil - 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:
scxml xmlns=http://www.w3.org/2005/07/scxml version=1.0
initialstate=state1
state id=state1
onentry
send event=foo/
/onentry
transition event=foo target=state2 /
/state
state id=state2 final=true /
/scxml
Therefore the invoke got stucked and the parent never received an
invoke.done event.
snip/
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)?
snip/
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: [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]) emma:emma version=1.0 emma:one-of id=r1 emma:start=1087995961542 emma:end=1087995963542 emma:interpretation id=int1 emma:confidence=0.75 emma:tokens=flights from boston to denver originBoston/origin destinationDenver/destination /emma:interpretation emma:interpretation id=int2 emma:confidence=0.68 emma:tokens=flights from austin to denver originAustin/origin destinationDenver/destination /emma:interpretation /emma:one-of /emma:emma 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? snip/ 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 assign 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]
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 snip/ (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: 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? snip/ 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... snip/ 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: [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 checksum *filename Please cast your vote. Thanks, Jochen [ ] +1 [ ] =0 [ ] -1 - 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? snip/ 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: moderators for [EMAIL PROTECTED]
On 7/2/07, Matt Benson [EMAIL PROTECTED] wrote: How arduous a task is it? snip/ 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]
[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:
scxml xmlns=http://www.w3.org/2005/07/scxml; version=1.0
initialstate=foo
state id=foo/
/scxml
bar.xml:
scxml xmlns=http://www.w3.org/2005/07/scxml; version=1.0
initialstate=bar
state id=bar/
/scxml
[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:reset but was:foo
junit.framework.ComparisonFailure: expected:reset but was:foo
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]
[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]
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: snip/ 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. snip/ 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. snip/ 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. snap/ 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? snap/ 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: [SCXML] Relation between data model names and event names ?
On 6/23/07, Ingmar Kliche [EMAIL PROTECTED] wrote: snip/ 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? snap/ :-) 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] 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. snip/ 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: [VOTE] Release commons-sandbox-parent 1
On 6/23/07, Phil Steitz [EMAIL PROTECTED] wrote: On 6/23/07, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ 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. snip/ 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, 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. snip/ 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] 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]
[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: [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]
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 snip/ 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. snap/ 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]
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: 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. snip/ 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]
[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, [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=revrev=548098 Log: Javadoc only: added notes about thread-safety to the most important Configuration implementations snip/ + + subsection name=Threading issues + p +The most concrete implementations of the codeConfiguration/code +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. + /p + /subsection snap/ 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]
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: snip/ How about: The most concrete implementations of the codeConfiguration/code 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. snap/ Yup, thanks! -Rahul Oliver BTW: Thanks for the hint. - 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]
[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-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]
[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] 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]
[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]
[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]
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). snip/ 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: [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. snip/ 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: [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. snip/ He switched in r545027 [1]. -Rahul [1] http://svn.apache.org/viewvc?view=revrevision=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 ... transition event=error target=errorstate / ... 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: datamodel data name=timer expr = '5'/ /datamodel state id=welcome onentry !-- start timer -- assign name=timer expr=timer - 1/ send event=timer delay=1s/ /onentry transition event=timer cond=timer 0 assign name=timer expr=timer - 1/ send event=timer delay=1s/ !-- do something -- /transition transition event=timer cond=timer == 0 target=somewhere/ /state This sample does not work as expected. All events are fired immediately and are not delayed. snip/ assign'ing a new value to the data named 'timer' generates a 'timer.change' event. The assumption of an ontology as stated above causes the transition event=timer ... to be immediately followed (all 5 of them, because there are 5 cascading assigns). 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. snap/ 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. snip/ 'Dotted names' are never recommended for use in documents with JEXL or EL expressions (so no dots in data or var 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: [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 snip/ 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. snap/ OK, thanks. -Rahul Jochen - 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. snip/ 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: [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. snip/ 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: [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=revrev=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 snip/ 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]
[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: [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. snip/ 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: [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=revrev=543799 Log: add new project stylesheet snip/ 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=autorev=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: [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=revrev=543805 Log: Put back the license. snip/ 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=diffrev=543805r1=543804r2=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 @@ +!-- + + 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. + +-- project xmlns=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; modelVersion4.0.0/modelVersion parent - 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? snip/ 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: [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=revrev=543799 Log: add new project stylesheet snip/ Missing props. I set eol-style.. doesn't need anything else, right? snip/ Yup, thats the one I cared about, thanks. -Rahul - 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 send with namelist: transition event=change if cond = _eventdata.eventSource == 'x' send targettype=GUI target='y' event=change namelist= _eventdata.eventValue / /if /transition As it does obviously not work it seems to me that the _eventdata structure is not accessible within a send 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 assign name=temp expr=_eventdata.eventValue/ and use temp within the send tags namelist attribute. But it would be more convenient to access it directly. What do you think? snip/ 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: [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. snip/ [X] +1 [ ] =0 [ ] -1 -Rahul - 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, snip/ 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: [functor] revival WAS Functor Users / Project Management?
On 5/30/07, Matt Benson [EMAIL PROTECTED] wrote: snip/ 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. :) snap/ 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: [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. snip/ [X] +1 [ ] =0 [ ] -1 - 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 send 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 send elements that create derived events should be handled, so for example: onentry send event=ev.foo namelist=alpha beta/ send event=ev.bar namelist=gamma delta/ /onentry 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 send events above could be processed by two regions like so: parallel state id=region1 transition event=ev.foo cond=_eventdatamap['ev.foo'].alpha eq 'somevalue' target=... / !-- ... -- /state state id=region2 transition event=ev.bar cond=_eventdatamap['ev.bar'].delta eq 'othervalue' target=... / !-- ... -- /state !-- ... -- /parallel To summarize, the _eventdatamap variable needs to be used in association with derived (such as send 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 send 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 send 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]
Re: [SCXML] sending internal events using send with payload
On 5/28/07, Ingmar Kliche [EMAIL PROTECTED] wrote: Rahul, the send 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 send tag including event payload ( i.e. namelist attribute). But as far as I understand the current implementation of send (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? snip/ 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. snip/ 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 scxml xmlns=http://www.w3.org/2005/07/scxml; version=1.0 initialstate=init ... /state state id=reset *transition event=watch.start target=running/ transition event=watch.start target=stopped/ *transition event=watch.split assign name=foo expr=3/ /transition /state 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!): SCXML : [/running, /stopped] 25.05.2007 16:27:01 org.apache.commons.scxml.env.SimpleErrorReporter onError WARNUNG: ILLEGAL_CONFIG (Multiple top-level OR states active!): SCXML : [/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: [beanutils] commons collection classes
On 5/18/07, Niall Pemberton [EMAIL PROTECTED] wrote: snip/ Having said that - the current situation has been in place for over 2 years and there haven't been complaints until now. snap/ 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: [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? snip/ 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: [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: [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? snip/ 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: [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? snip/ 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 anchors 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? snap/ 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? snip/ 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=revrev=532478 Log: Feb '07 WD conformance changes for the IO package: - Update parser to support final, changed usage of parallel - 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]
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? snip/ 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=revrevision=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: [EMAIL PROTECTED] wrote: Author: tcurdt Date: Tue Apr 17 16:46:08 2007 New Revision: 529805 URL: http://svn.apache.org/viewvc?view=revrev=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=diffrev=529805r1=529804r2=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 @@ -?xml version=1.0 encoding=ISO-8859-1? +?xml version=1.0? project name=Jakarta Commons JCI bannerRight nameJakarta Commons JCI/name @@ -7,10 +7,10 @@ /bannerRight body menu name=Jakarta Commons JCI -item name=About href=index.html/ -item name=Usage href=usage.html/ -item name=FAQ href=faq.html/ -item name=Downloads href=downloads.html/ +item name=About href=http://jakarta.apache.org/commons/jci/index.html/ +item name=Usage href=http://jakarta.apache.org/commons/jci/usage.html/ +item name=FAQ href=http://jakarta.apache.org/commons/jci/faq.html/ +item name=Downloads href=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. snip/ 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: 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=revrev=529805 Log: rephrased a few o=paragraphs, fixed broken links snip/ 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. snip/ 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? snap/ Before, yes. -Rahul -- Dennis Lundberg - 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: snip/ 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. snap/ 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]
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=revrev=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!)
snip/
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 artifactId 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]
[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: 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=revrev=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=diffrev=529017r1=529016r2=529017 == Binary files - no diff available. snip/ Binary? -Rahul - 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=revrev=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=autorev=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 @@ +?xml version=1.0 encoding=UTF-8? +!-- + 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. +-- +project +xmlns=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; + parent +groupIdorg.apache.commons/groupId +artifactIdcommons-parent/artifactId +version1/version + /parent + modelVersion4.0.0/modelVersion + groupIdcommons-cli-avalon/groupId + artifactIdcommons-cli-avalon/artifactId snip/ Since this a new component, we should preferably discuss its creation (then have a vote if needed etc.). -Rahul + version2.0-SNAPSHOT/version + nameCLI-Avalon/name + + inceptionYear2002/inceptionYear + description +Commons CLI (Avalon) provides a simple API for processing and +validating a command line interface. + /description + + urlhttp://jakarta.apache.org/commons/cli//url + + issueManagement +systemjira/system +urlhttp://issues.apache.org/jira/browse/CLI/url + /issueManagement + + scm + connectionscm:svn:http://svn.apache.org/repos/asf/jakarta/commons/proper/cli/branches/avalon-implementation/connection + developerConnectionscm:svn:https://svn.apache.org/repos/asf/jakarta/commons/proper/cli/branches/avalon-implementation/developerConnection + urlhttp://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/avalon-implementation/url + /scm + + + dependencies + +!-- used for unit tests -- +dependency + groupIdjunit/groupId + artifactIdjunit/artifactId + version3.8.1/version + scopetest/scope +/dependency + +!-- used for unit tests -- +dependency + groupIdjdepend/groupId + artifactIdjdepend/artifactId + version2.5/version + scopetest/scope +/dependency + + /dependencies + + build +sourceDirectorysrc/java/sourceDirectory +testSourceDirectorysrc/test/testSourceDirectory +resources +resource + directorysrc/java/org/apache/commons/cli/avalon/directory + targetPathorg/apache/commons/cli/avalon/targetPath + includes +include**/*.properties/include + /includes +/resource +resource + directory./directory + targetPathMETA-INF/targetPath + includes +includeNOTICE.txt/include +includeLICENSE.txt/include + /includes +/resource +/resources + /build + +/project \ 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]
[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.connectionmanager.CachedConnectionInterceptor.invoke( CachedConnectionInterceptor.java:158) at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInt erceptor.java:63) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterce ptor.java:121) at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInte
[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. ?xml version=1.0? !-- Used for comparison with custom-hello-world.xml by CustomActionTest.java in model package -- scxml xmlns=http://www.w3.org/2005/07/scxml; xmlns:my=http://my.custom-actions.domain/CUSTOM; version=1.0 initialstate=testMain state id=testMain parallel state id=slotState initial transition target next=MSlotInitState / /transition /initial state id=MSlotInitState initial /initial onentry log expr='Slot Init State' / /onentry transition event=CreateATaskEvent cond=_eventdata.slotAvailable=true target=MSlotHeldState.aquireSlot / transition event=CreateATaskEvent cond=_eventdata.slotavailable=true target=MSlotLockedState.lockSlot/ transition event=CreateATaskEvent cond=!_eventdata.slotAvailable target=MSlotQueuedState.queueSlot / /state state id=MSlotLockedState onentry log expr='Slot Locked State' / /onentry transition event=CancelEvent target=MSlotCancelledState.freeSlot / /state state id=MSlotCancelledState.freeSlot onentry log expr='Slot Cancelled or Freed State' / /onentry /state state id=MSlotHeldState.aquireSlot onentry log expr='Slot Held State' / /onentry transition event=JobCompleteEvent target=MSlotFreedState.releaseSlot / /state state id=MSlotLockedState.lockSlot onentry log expr='Slot locked State'/ /onentry transition event=SlotReadyToBeHeldEvent target=MSlotHeldState.aquireSlot / /state state id=MSlotQueuedState.queueSlot onentry log expr='Slot Queued State' / /onentry /state
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/ snip/ 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/ snap/ 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]
Re: [all] Going TLP?
On 4/2/07, Henri Yandell [EMAIL PROTECTED] wrote: On 4/2/07, Phil Steitz [EMAIL PROTECTED] wrote: snip/ +0 for waiting to do this until we have a clear idea of where the rest of the Jakarta subprojects are going. Once we go TLP, I imagine a few would head in our direction, whereas until we go TLP there won't be much of a decision made either way. I know I plan to suggest that the RDC taglib moves to Commons so it can be with SCXML (they're fairly tied aren't they?), snap/ They're now decoupled (once we extracted the SCXML codebase out to Commons). There is a dependency on Commons SCXML (the RDC taglib uses it as one of the strategies to manage dialogs in speech applications). Having said that, the RDC taglib is: * Fairly small * A library with a well-defined scope * Mostly in Java, the rest is JSP tag files As you said, its going to be influenced by what goes in the resolution. Is the proposed TLP strictly Java only? Is a JSP taglib a Java library? Probably more Java than Ruby. Its for all of us to decide these things, and make it part of the resolution. If it fits, it should come. and then the other parts of Taglibs can be put gently to sleep (unsure on JSTL). snip/ Doesn't look like there is any new JSTL development planned here. I do intend to go through the RDC bugzilla and a couple of enhancement requests in there, its not high priority ATM. -Rahul Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Commons DBCP 1.2.2 (reprise)
On 3/25/07, Phil Steitz [EMAIL PROTECTED] wrote: I have fixed the JRockit test compatibility issue raised during the first DBCP 1.2.2 release vote and would like to kick off a new release vote based on RC3, with links provided below. snip/ +1 -Rahul Since RC2, the following changes have been made; * Fixed JRockit test compatibility issue (tested with Linux versions of jrockit-R27.1.0-jdk1.5.0_08, jrockit-R27.1.0-jdk1.4.2_12, and jrockit-jdk1.5.0_06) * Added a note to release notes and README calling out the lack of JDK 1.6 / JDBC 4.0 support * Fixed 'Built-By' manifest attribute The release zips/tarballs are here: http://people.apache.org/~psteitz/dbcp-1.2.2-RC3/http://people.apache.org/%7Epsteitz/dbcp-1.2.2-RC1/ Please note that, despite the release names, these distributions are *not* official apache releases, so should be used only for inspection/verification during the duration of this VOTE. Release notes: http://people.apache.org/~psteitz/dbcp-1.2.2-RC3/RELEASE-NOTES.txt http://people.apache.org/%7Epsteitz/dbcp-1.2.2-RC1/RELEASE-NOTES.txt Web site: http://people.apache.org/~psteitz/dbcp-1.2.2-RC3/docs/http://people.apache.org/%7Epsteitz/dbcp-1.2.2-RC1/docs/ The svn tag is DBCP_1_2_2-RC3. Assuming a successful VOTE, I will copy the tag to DBCP_1_2_2 and move the distributions above to the mirrors. Votes, please. The vote will close end of day (GMT) 28-March-2007. Thanks! Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] jci out of sandbox
On 3/28/07, Torsten Curdt [EMAIL PROTECTED] wrote: As already announced I would like to move http://jakarta.apache.org/commons/sandbox/jci/ out of the sandbox so I can then prepare a first RC. Please cast your votes for the graduation! snip/ +0 I won't be able to help or get involved any time soon (other than looking over RCs when I can etc.) but its good stuff and wanted to show some support anyway. -Rahul cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (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 updated SCXML-41: --- Fix Version/s: 0.7 Assignee: Rahul Akolkar Affects Version/s: 0.6 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 Assigned To: 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]
[jira] Updated: (SCXML-40) provide a mechanism to add a session Id to current var, assign traces using a new Executor member.
[ https://issues.apache.org/jira/browse/SCXML-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Akolkar updated SCXML-40: --- Fix Version/s: 0.7 Assignee: Rahul Akolkar Affects Version/s: 0.6 provide a mechanism to add a session Id to current var, assign traces using a new Executor member. -- Key: SCXML-40 URL: https://issues.apache.org/jira/browse/SCXML-40 Project: Commons SCXML Issue Type: Improvement Affects Versions: 0.6 Reporter: Nestor Urquiza Assigned To: Rahul Akolkar Fix For: 0.7 In a concurrent environment like a web application it is of a tremendous important to get the Session Id together with any log trace. Given the fact an executor defines uniquely a State Machine status at any time it is the executor the one that ideally should carry an identifier. I would allow that identifier to be accessible with getter/setter methods. That way one can decide to set the exec#id with the session Id and later that member could be used to be output as part of the current var, assign traces. -- 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] Updated: (SCXML-39) Deprecations associated with Feb '07 WD changes
[ https://issues.apache.org/jira/browse/SCXML-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Akolkar updated SCXML-39: --- Description: Placeholder issue for listing all deprecations introduced by changes in the Feb '07 WD. 1) State#getTransitions(): * In favor of getTransitionsList() which helps better retain document order. * Deprecated in r515834 while at 0.7-SNAPSHOT. 2...n) TODO: complete this was: In favor of getTransitionsList() which helps better retain document order. Deprecated in r515834 while at 0.7-SNAPSHOT. Remove before v1.0. Summary: Deprecations associated with Feb '07 WD changes (was: Deprecate State#getTransitions()) Deprecations associated with Feb '07 WD changes --- Key: SCXML-39 URL: https://issues.apache.org/jira/browse/SCXML-39 Project: Commons SCXML Issue Type: Task Affects Versions: 0.6 Reporter: Rahul Akolkar Assigned To: Rahul Akolkar Fix For: 1.0 Placeholder issue for listing all deprecations introduced by changes in the Feb '07 WD. 1) State#getTransitions(): * In favor of getTransitionsList() which helps better retain document order. * Deprecated in r515834 while at 0.7-SNAPSHOT. 2...n) TODO: complete 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: [Patch] jxpath typo in user guide
On 3/22/07, Kevin Jackson [EMAIL PROTECTED] wrote: Hi, I noticed this small typo so here's a patch to correct it snip/ Patch did not make it to the list (atleast my mailbox). Suggest using JIRA [1]. -Rahul [1] http://issues.apache.org/jira/browse/JXPATH Thanks, Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New committer - Stephen Kestle
On 3/20/07, Stephen Colebourne [EMAIL PROTECTED] wrote: Stephen has spent a considerable amount of effort in discussions and chivying in the commons area, particularly on commons-collections. In another life he has been heavily involved in one of the existing generics ports of collections - http://collections.sf.net. [X] +1 - Let him commit [ ] 0 [ ] -1 - Perhaps not... snip/ -Rahul Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New committer - Stephen Kestle
On 3/21/07, Stephen Kestle [EMAIL PROTECTED] wrote: snip/ Just out of interest, are people voting for me because: * of Stephen (C)'s recommendation * of my correspondance (do people actually read all these emails?) * it's the cool thing to do / I seem to be ok snap/ I will reply candidly, take it FWIW (one opinion). * The scolebourne commits have been a significant part of [collections] (amongst other places), and if he thinks you fit the bill, thats a plus. * I do try to read every post on this list (including svn commits and JIRA comments) -- and I usually can. Much of your recent input seems to make sense. * This should have been two bullets *shrug*. On the second part, you seem a bit green here (for example, voting for oneself is more or less unnecessary and depending on the subject and context of the vote etc. asking why someone voted in favor may not be perceived to be in good taste -- its somewhat accepted that others really don't need to know). Obviously, this bit can change over time so I voted the way I did. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New committer - Stephen Kestle
On 3/21/07, Stephen Kestle [EMAIL PROTECTED] wrote: snip/ Thanks for the answer - apologies to those who thought my questions a bit forward (I was only intending to get a reply or two). snap/ Nah, not my intent at all, no apologies necessary IMO. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jexl] PROPOSAL: Extend Jexl to Support comparison operations between used-defined types
Please open an enhancement request in JIRA [1]. Proposals on the
mailing list tend to get lost unless there is immediate interest /
cycles available. Thanks.
-Rahul
[1] http://issues.apache.org/jira/browse/JEXL
On 3/17/07, Dimitri Papaioannou [EMAIL PROTECTED] wrote:
Please let me know if you aagree with the following proposal:
I would like to extend Jexl to support comparison operations between
used-defined types.
This will enable Jexl to do comparison operations between user-define data
types that are not a-priori comparable. For example, you will be able to
compare dates to strings representing dates, numbers to strings formatted as
percentages et cetera.
This will be accomplished by implementing custom type converters:
public interface TypeConverter {
public Object convert(JexlContext context, Object object) throws
TypeConversionException ;
}
And registering them with the context:
JexlContext context = JexlHelper.createContext();
context.registerConverter(Date.class, converter);
These are some sample usages in unit-test form:
public void testDateComparison() throws Exception {
SimpleDateTypeConverter converter = new
SimpleDateTypeConverter();
context.registerConverter(Date.class, converter);
Calendar c1 = new GregorianCalendar(2006,
Calendar.MARCH, 4);
context.getVars().put(date, c1.getTime());
assertTrue(date '2007-01-01');
assertTrue('2006-01-01' date);
converter.registerFormat(MM/dd/yy);
assertTrue(date == '3/4/06');
}
public void testUserDefinedType() throws Exception {
context.registerConverter(Temperature.class, new
TypeConverter() {
public Object convert(JexlContext
context, Object object) throws TypeConversionException {
if (object == null) {
return null;
}
if (object instanceof
Temperature) {
return
(Temperature) object;
}
String str = object.toString
();
return Temperature.valueOf
(str);
}
});
context.getVars().put(temp, Temperature.COLD);
assertTrue(temp == 'COLD');
assertTrue(temp 'HOT');
assertTrue('MEDIUM' temp);
}
public void testExtendTypeConverter() throws Exception {
context.registerConverter(Float.class, new PercentConverter());
context.registerConverter(Double.class, new PercentConverter());
context.registerConverter(BigDecimal.class, new PercentConverter());
assertTrue(0.14 == '14%');
context.getVars().put(a, new BigDecimal(0.65));
assertTrue(a '70%');
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [CLI] svn commit: r518681 - /jakarta/commons/trunks-proper/
On 3/15/07, Henri Yandell [EMAIL PROTECTED] wrote: On 3/15/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 3/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: bayard Date: Thu Mar 15 09:31:32 2007 New Revision: 518681 URL: http://svn.apache.org/viewvc?view=revrev=518681 Log: Adding CLI 1 and CLI Avalon to the list of active trunks snip/ I don't like this idea of having multiple trunks per component via externals. Generally this seems liable to foster confusion. Only the best guess estimate of the line of development going into the next release should be here, IMO. Yup. That is my best guess :) snip/ You should be entitled to only one guess :-) So its three components pretending to be one, and I see (in another thread) that you're planning on releasing from all three lines (ugh -- what a mess). -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 3/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jochen
Date: Thu Mar 15 15:02:46 2007
New Revision: 518770
URL: http://svn.apache.org/viewvc?view=revrev=518770
Log:
Made the FileCleaningTracker serializable.
This is required by commons-fileupload, because the
DiskFileItem's may be part of the HTTP session while
still carrying a reference to the tracker.
snip/
I think this particular solution is sub-optimal in a couple of aspects:
* The instances aren't really serializable so its a bit of a truth in
advertising infringement
* Its introducing a tighter coupling between the next releases of
[io] and [fileupload], which is fine if we can buy that there is
evidence that the change would be helpful to [io] in isolation.
I think identical behavior (for what this is worth) can be obtained by
reverting this commit and having a transient lazily-initialized
FileCleaningTracker in DiskFileItem, which addresses the two bullets
above, and the NotSerializableExceptions that you may otherwise
witness at container shutdown.
WDYT?
-Rahul
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaningTracker.java
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/FileUtilsCleanDirectoryTestCase.java
Modified:
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaningTracker.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaningTracker.java?view=diffrev=518770r1=518769r2=518770
==
---
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaningTracker.java
(original)
+++
jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileCleaningTracker.java
Thu Mar 15 15:02:46 2007
@@ -17,6 +17,8 @@
package org.apache.commons.io;
import java.io.File;
+import java.io.ObjectStreamException;
+import java.io.Serializable;
import java.lang.ref.PhantomReference;
import java.lang.ref.ReferenceQueue;
import java.util.Collection;
@@ -40,23 +42,28 @@
* @author Martin Cooper
* @version $Id: FileCleaner.java 490987 2006-12-29 12:11:48Z scolebourne $
*/
-public class FileCleaningTracker {
+public class FileCleaningTracker implements Serializable {
+/**
+ * UID for serializing instances of this class.
+ */
+private static final long serialVersionUID = -8153509976492548871L;
+
/**
* Queue of codeTracker/code instances being watched.
*/
-ReferenceQueue /* Tracker */ q = new ReferenceQueue();
+transient ReferenceQueue /* Tracker */ q = new ReferenceQueue();
/**
* Collection of codeTracker/code instances in existence.
*/
-final Collection /* Tracker */ trackers = new Vector(); // synchronized
+final transient Collection /* Tracker */ trackers = new Vector(); //
synchronized
/**
* Whether to terminate the thread when the tracking is complete.
*/
-volatile boolean exitWhenFinished = false;
+transient volatile boolean exitWhenFinished = false;
/**
* The thread that will clean up registered files.
*/
-Thread reaper;
+transient Thread reaper;
//---
/**
@@ -255,4 +262,14 @@
}
}
+/**
+ * This method is called when an instance is deserialized.
+ * It replaces the deserialized instance with a new, fresh
+ * instance.
+ * @return A new instance, which hasn't been in use so far.
+ * @throws ObjectStreamException Not actually thrown.
+ */
+private Object readResolve() throws ObjectStreamException {
+return new FileCleaningTracker();
+}
}
Modified:
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/FileUtilsCleanDirectoryTestCase.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/FileUtilsCleanDirectoryTestCase.java?view=diffrev=518770r1=518769r2=518770
==
---
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/FileUtilsCleanDirectoryTestCase.java
(original)
+++
jakarta/commons/proper/io/trunk/src/test/org/apache/commons/io/FileUtilsCleanDirectoryTestCase.java
Thu Mar 15 15:02:46 2007
@@ -103,7 +103,7 @@
}
public void testThrowsOnNullList() throws Exception {
-if (!chmod(top, 0, false)) {
+if (System.getProperty(os.name).startsWith(Win) || !chmod(top,
0, false)) {
// test wont work if we can't restrict permissions on the
// directory, so skip it.
return;
@@ -122,7 +122,7 @@
final File file = new File(top, restricted);
FileUtils.touch(file);
-if (!chmod(top, 500, false)) {
+if (System.getProperty(os.name).startsWith(Win) || !chmod(top,
500, false)) {
// test wont work if we
Re: [cli] findings...
On 3/16/07, Torsten Curdt [EMAIL PROTECTED] wrote: OK ...so here is the story. There is bug in the 1.0 release of CLI that I've encountered a couple of times now. This time while I was writing a javac compatible command line interface for the jci examples. So I thought I have a look at the source, but what a mess! Just have a look here: http://svn.apache.org/viewvc/jakarta/commons/proper/cli/branches/ I wasn't even clear what to compile and use. So I did a svn log on all 3 possible candidates. svn log --stop-on-copy http://svn.apache.org/repos/asf/jakarta/ commons/proper/cli/branches/CLI_1_BRANCH/ svn log --stop-on-copy http://svn.apache.org/repos/asf/jakarta/ commons/proper/cli/branches/CLI_1_0_1_prepare/ svn log --stop-on-copy http://svn.apache.org/repos/asf/jakarta/ commons/proper/cli/branches/cli-1.0.x/ My interpretation (please correct me if I am wrong) is that CLI_1_BRANCH was the original branch from the CVS migration. The CLI_1_0_1_prepare even has still the old ASL 1.1 header. The cli-1.0.x seems to have the latest changes and be the real thing. A snapshot compile did in fact solve the problem I had with jci. IMO we *have* to clean up this mess. I am not sure how much time I can devote atm - but I will try to help. This has bitten me too often now. So here is my proposal: 1) Let's do a bug fix release 1.0.1 from cli-1.0.x ASAP. cli-1.0.x should become the official bug fix release branch for version 1. 2) Let's remove all other 1.x branches (CLI_1_0_1_prepare, CLI_1_BRANCH) 3) Let's remove the commons-configuration-integration and RESEARCH_CLI_2_ROXSPRING branch. There was no activity within the past 20 months unless I am mistaken. So I think we can safely say these tries were dead-ends. 4) Let's remove the CLI_2_DEV_BRANCH. What's that needed for? Trunk is now 2.x 5) Let's move the avalon-implementation branch into the sandbox. It's a completely different implementation and has nothing to do with commons-cli ...except sharing a common problem space maybe. Again not much activity either. Once that is done it might be worth having a look to get trunk on the way. But well ...one step at a time :) snip/ Good stuff. -Rahul cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jci] out of the sandbox
On 3/16/07, Torsten Curdt [EMAIL PROTECTED] wrote: I'd like to bring this well before an actual vote. At the moment I am still in the middle of documenting and fixing up JCI for a first 1.0 release. I hope to be able to provide a first RC1 at the end of next week ...latest the week after. There are a few things about JCI that are worth talking about. snip-community/ 2) Multi-project JCI uses the maven2 multi-project feature for modularity. Now this makes it the first multi-project release in commons and question is how we should handle versioning and voting procedure. In theory it would be good to be able to have individual releases of the modules. Suggestions are welcome. snap/ Seems like a bad idea for a Commons component: * Potential confusion due to version numbers of modules moving independently etc.. * Its unlikely that releasing one module is significantly easier than releasing all. * Its likely that even though after a given quantum of time major changes are in one module (hence the temptation to release separately), there will probably be little changes elsewhere that are good to push out anyway * Data points around us -- even larger multi-project m2 builds like Shale (Struts too, I believe) release all bits together (yes, not all reasons there make sense here, but ... data points). 3) Site Another thing that comes with the multi-module is that (unfortunately) maven's multi-project reporting facilities still suck! At the moment this still means that some of reports are just empty. The only other option would be to have a sub-site for each individual model - but for JCI that would be just overkill. Please just have a look what needs to be changed for a release. http://jakarta.apache.org/commons/sandbox/jci/ snip/ How about: * A little guide? Tiny code snippets? * package.html files? 3) groupId I would like to use the proper maven2 groupId naming scheme for JCI. snap/ Sure. -Rahul Thoughts? cheers -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [CLI] svn commit: r518681 - /jakarta/commons/trunks-proper/
On 3/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: bayard Date: Thu Mar 15 09:31:32 2007 New Revision: 518681 URL: http://svn.apache.org/viewvc?view=revrev=518681 Log: Adding CLI 1 and CLI Avalon to the list of active trunks snip/ I don't like this idea of having multiple trunks per component via externals. Generally this seems liable to foster confusion. Only the best guess estimate of the line of development going into the next release should be here, IMO. -Rahul Modified: jakarta/commons/trunks-proper/ (props changed) Propchange: jakarta/commons/trunks-proper/ -- --- svn:externals (original) +++ svn:externals Thu Mar 15 09:31:32 2007 @@ -3,6 +3,8 @@ betwixt https://svn.apache.org/repos/asf/jakarta/commons/proper/betwixt/trunk chain https://svn.apache.org/repos/asf/jakarta/commons/proper/chain/trunk cli https://svn.apache.org/repos/asf/jakarta/commons/proper/cli/trunk +cli-avalon https://svn.apache.org/repos/asf/jakarta/commons/proper/cli/branches/avalon-implementation +cli-1.0.x https://svn.apache.org/repos/asf/jakarta/commons/proper/cli/branches/cli-1.0.x codec https://svn.apache.org/repos/asf/jakarta/commons/proper/codec/trunk collections https://svn.apache.org/repos/asf/jakarta/commons/proper/collections/trunk commons-build https://svn.apache.org/repos/asf/jakarta/commons/proper/commons-build/trunk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Brainstorming for 2.0
On 3/12/07, Martin Cooper [EMAIL PROTECTED] wrote: On 3/12/07, Oliver Zeigermann [EMAIL PROTECTED] wrote: I have now created a Wiki page for the 2.0 discussion: http://wiki.apache.org/jakarta-commons/Brainstorm_2%2e0 Not a particularly good page name, given that it's not scoped to Transaction in a any way. It could apply equally well to any Commons component heading for 2.0. snip/ Had the same reaction, felt like adding a couple of pointers -- for help, see: http://wiki.apache.org/jakarta-commons/HelpContents For example, see: http://wiki.apache.org/jakarta-commons/SCXML/Tutorials/History You can rename by choosing Rename Page from the More Actions: dropdown from the menu towards the top of the page. -Rahul -- Martin Cooper 2007/3/9, Oliver Zeigermann [EMAIL PROTECTED]: Packae naming: As discussed here http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200611.mbox/[EMAIL PROTECTED] it might be a good idea to have a new package name for the 2.x version. I'd be +1 for that Oliver 2007/3/4, Oliver Zeigermann [EMAIL PROTECTED]: Folks! As explaining in my previous post, I have created a new TRANSACTION2 branch to contain initial code, docs, etc. for a future 2.0 version of Commons Transaction. If you have ideas, suggestions, etc. please follow up to this post until we find a more suitable place for such a discussion. Open Questions (my suggestions in brackets): 1.) Medium for discussion (Wiki? SVN?) 2.) Library requirement (1.5 concurrent package?) 3.) Minimum JDK Requirement (always the latest, i.e. 1.6) 4.) Scope (all restricted as possible) 5.) What else? Cheers Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
