Re: [scxml-eclipse] JIRA housekeeping

Hi Rahul, Thank you for your remind,I will resolve all the finished JIRA issues about SCXML-Eclipse in JIRA system, and give a solution to SCXML-152. In the coming days, i will try my best to give response to JIRA issues as soon as possible 2010/7/23 Rahul Akolkar > Long, > > Couple of weeks or

[scxml-eclipse] JIRA housekeeping

Long, Couple of weeks or so ago, I had mentioned leaving a few JIRA issues open. Since then, I have had a chance to try out some of the code. Please resolve those JIRA issues as completed / as you may see fit. Thanks. On a separate note, over the years, I've tried to evaluate and offer an initial

Re: [scxml-eclipse] Current State

On Thu, Jul 22, 2010 at 5:13 PM, Christopher Dragert wrote: > Hello, > > I've begun experimenting and had some difficulties with basic functionality.   > For instance, it does not seem to have basic functionality of creating an > scxml file from an scxml drawing.  It only outputs scxml to the con

Re: [Digester] Sandbox "annotations" package ready to be revisioned and merged to /trunk

On Wed, Jul 21, 2010 at 4:01 PM, Simone Tripodi wrote: > Hi all guys, > as discussed and agreed with Rahul[1] last week, I added the missing - > hopefully, detailed - package documentation on the "annotations" > package on the sandbox digester[2] and merged latest trunk > modifications, re-execute

Re: [scxml-eclipse] Current State

Hi Chris, You can find basic guide document here [1]. I think you should export SCXML document from modeling document which contains tag 'targetConnection'. [1] http://commons.apache.org/sandbox/gsoc/2010/scxml-eclipse/guide/using-visual-scxml.html 2010/7/23 Christopher Dragert > Hello, > > I

Re: clirr for MATH-389

Le 22/07/2010 23:35, Gilles Sadowski a écrit : No, it was intentional so users can explicitly refer to it when building the instance. >>> >>> Intentional but still a mistake IMO ;-) as it's part of the interface >>> whereas the prime use is to allow to define a default constructor so that

Re: clirr for MATH-389

> >> No, it was intentional so users can explicitly refer to it when building > >> the instance. > > > > Intentional but still a mistake IMO ;-) as it's part of the interface > > whereas the prime use is to allow to define a default constructor so that > > the user does *not* have to refer to the

Re: [lang] Change artifactId to commons-lang3 for trunk...

http://people.apache.org/~bayard/commons-lang-3.0-beta-1/site/apidocs/index.html But I'll update the website a bit so it's easy to find when I republish. On Thu, Jul 22, 2010 at 2:00 PM, Paul Benedict wrote: > If you haven't already, can you publish the beta-1 API before the vote? > > On Thu, Ju

[scxml-eclipse] Current State

Hello, I've begun experimenting and had some difficulties with basic functionality. For instance, it does not seem to have basic functionality of creating an scxml file from an scxml drawing. It only outputs scxml to the console, without the linebreaks necessary for readabilty. Transitions s

Re: [lang] Change artifactId to commons-lang3 for trunk...

If you haven't already, can you publish the beta-1 API before the vote? On Thu, Jul 22, 2010 at 3:59 PM, Henri Yandell wrote: > Just let me know when everything is resolved and I can repeat :) > >

Re: [lang] Change artifactId to commons-lang3 for trunk...

Just let me know when everything is resolved and I can repeat :) On Thu, Jul 22, 2010 at 12:13 PM, James Carman wrote: > Henri, > > Since I srewed everything up (artifactId, EventListenerSupport, etc.), > do you want me to re-cut the 3.0-beta release?  I think we should try > to make sure all thi

Re: svn commit: r966839 - in /commons/proper/proxy/branches/version-2.0-work: ./ test/ test/src/ test/src/main/ test/src/main/java/ test/src/test/ test/src/test/java/ test/src/test/java/org/ test/src/

On Jul 22, 2010, at 3:31 PM, Jörg Schaible wrote: > sebb wrote: > >> On 22 July 2010 21:15, wrote: >>> Author: mbenson >>> Date: Thu Jul 22 20:15:25 2010 >>> New Revision: 966839 >>> >>> URL: http://svn.apache.org/viewvc?rev=966839&view=rev >>> Log: >>> add new test module to exercise the def

Re: clirr for MATH-389

Le 22/07/2010 17:08, Gilles Sadowski a écrit : >>> Concerning the items related to this issue: >>> >>> 3rd item: The method is declared in a superclass. >>> 4th item: The constant is defined in a superclass. It is still "public" but >>> I think that it's a mistake and should be made "private" inste

Re: svn commit: r966839 - in /commons/proper/proxy/branches/version-2.0-work: ./ test/ test/src/ test/src/main/ test/src/main/java/ test/src/test/ test/src/test/java/ test/src/test/java/org/ test/src/

sebb wrote: > On 22 July 2010 21:15, wrote: >> Author: mbenson >> Date: Thu Jul 22 20:15:25 2010 >> New Revision: 966839 >> >> URL: http://svn.apache.org/viewvc?rev=966839&view=rev >> Log: >> add new test module to exercise the defaultProxyFactory >> >> Added: >> commons/proper/proxy/branches/ve

Re: svn commit: r966779 - in /commons/proper/proxy/branches/version-2.0-work/core/src/main/java/org/apache/commons/proxy2: DefaultProxyFactory.java ProxyUtils.java

Wow, a rash of these. Apparently I've not yet set this up on my new drive. :/ On Jul 22, 2010, at 3:23 PM, sebb wrote: > On 22 July 2010 19:14, wrote: >> Author: mbenson >> Date: Thu Jul 22 18:14:42 2010 >> New Revision: 966779 >> >> URL: http://svn.apache.org/viewvc?rev=966779&view=rev >> L

Re: svn commit: r966779 - in /commons/proper/proxy/branches/version-2.0-work/core/src/main/java/org/apache/commons/proxy2: DefaultProxyFactory.java ProxyUtils.java

On 22 July 2010 19:14, wrote: > Author: mbenson > Date: Thu Jul 22 18:14:42 2010 > New Revision: 966779 > > URL: http://svn.apache.org/viewvc?rev=966779&view=rev > Log: > add ProxyFactory that delegates to discovered service providers > > Added: >     > commons/proper/proxy/branches/version-2.0-w

Re: svn commit: r966839 - in /commons/proper/proxy/branches/version-2.0-work: ./ test/ test/src/ test/src/main/ test/src/main/java/ test/src/test/ test/src/test/java/ test/src/test/java/org/ test/sr

On 22 July 2010 21:15, wrote: > Author: mbenson > Date: Thu Jul 22 20:15:25 2010 > New Revision: 966839 > > URL: http://svn.apache.org/viewvc?rev=966839&view=rev > Log: > add new test module to exercise the defaultProxyFactory > > Added: >    commons/proper/proxy/branches/version-2.0-work/test/  

Re: [compress] release 1.1?

>> whenever one want to get to the properties of an ArchiveEntry one has >> to figure out what actual implementation it is. > > I know what you mean > Exactly ...and look how s

Re: OS400FTPEntryParser Fix

On 22 July 2010 16:33, Big Jim wrote: > I have discovered a bug in > org.apache.commons.net.ftp.parser.OS400FTPEntryParser.java.  The variable > "private static final String DEFAULT_DATE_FORMAT" needs to be changed from > "yy/MM/dd HH:mm:ss"; //01/11/09 12:30:24 to "MM/dd/yy HH:mm:ss"; //01/15/08

Re: [lang] Change artifactId to commons-lang3 for trunk...

Ok, it's already changed in trunk. If we come up with a good reason to change it back, we can do so easily. On Thu, Jul 22, 2010 at 3:35 PM, Paul Benedict wrote: > +1 too. > > On Thu, Jul 22, 2010 at 2:11 PM, Henri Yandell wrote: > >> I was -1, but the below is a good argument. +1. >> >> On Thu

Re: [lang] Change artifactId to commons-lang3 for trunk...

+1 too. On Thu, Jul 22, 2010 at 2:11 PM, Henri Yandell wrote: > I was -1, but the below is a good argument. +1. > > On Thu, Jul 22, 2010 at 12:08 PM, James Carman > wrote: > > Well, I think changing the artifactId right now would be the way to > > go. That keeps things consistent. If we move

Re: [lang] Change artifactId to commons-lang3 for trunk...

That's "screwed" not "srewed" On Thu, Jul 22, 2010 at 3:13 PM, James Carman wrote: > Henri, > > Since I srewed everything up (artifactId, EventListenerSupport, etc.), > do you want me to re-cut the 3.0-beta release?  I think we should try > to make sure all this is fixed before we "release" a bet

Re: [lang] Change artifactId to commons-lang3 for trunk...

Henri, Since I srewed everything up (artifactId, EventListenerSupport, etc.), do you want me to re-cut the 3.0-beta release? I think we should try to make sure all this is fixed before we "release" a beta. James On Thu, Jul 22, 2010 at 3:11 PM, Henri Yandell wrote: > I was -1, but the below is

Re: [lang] Change artifactId to commons-lang3 for trunk...

I was -1, but the below is a good argument. +1. On Thu, Jul 22, 2010 at 12:08 PM, James Carman wrote: > Well, I think changing the artifactId right now would be the way to > go.  That keeps things consistent.  If we move to org.apache.commons > groupId now and don't change the artifactId and then

Re: [lang] Change artifactId to commons-lang3 for trunk...

Well, I think changing the artifactId right now would be the way to go. That keeps things consistent. If we move to org.apache.commons groupId now and don't change the artifactId and then later, if we release 4.x, we change the package to lang4 and the artifactId to commons-lang4 it will just be

Re: [VOTE] Release Commons Lang 3.0 Beta.1

On Jul 22, 2010, at 1:34 PM, Michael Wooten wrote: > I've been talking it over with James and we've considered the option > of swapping the inheritance chain so that there is an > EventListenerSource class that extends EventListenerSupport but > includes the "source" property and documentation on

Re: [lang] Change artifactId to commons-lang3 for trunk...

We don't need the artifact name to necessarily contain the version name since the group is different. We already have achieved parallel installs just by doing that. I see two choices for the FQN: org.apache.commons:commons-lang3:3.0-beta-1 org.apache.commons:commons-lang:3.0-beta-1 Which do you f

Re: [lang] Change artifactId to commons-lang3 for trunk...

Yes, it's org.apache.commons:commons-lang3 On Thu, Jul 22, 2010 at 3:00 PM, Paul Benedict wrote: > And we have abandoned commons-lang as the groupId, right? > > On Thu, Jul 22, 2010 at 1:57 PM, James Carman > wrote: > >> Ok, just wanted to make sure I wasn't off base here.  Want me to >> commi

Re: [lang] Change artifactId to commons-lang3 for trunk...

On Jul 22, 2010, at 2:00 PM, Paul Benedict wrote: > And we have abandoned commons-lang as the groupId, right? > Correct. > On Thu, Jul 22, 2010 at 1:57 PM, James Carman > wrote: > >> Ok, just wanted to make sure I wasn't off base here. Want me to >> commit it (it's change on my local)? >> >

Re: [lang] Change artifactId to commons-lang3 for trunk...

And we have abandoned commons-lang as the groupId, right? On Thu, Jul 22, 2010 at 1:57 PM, James Carman wrote: > Ok, just wanted to make sure I wasn't off base here. Want me to > commit it (it's change on my local)? > > On Thu, Jul 22, 2010 at 2:52 PM, Paul Benedict > wrote: > > +1. One goal th

Re: [lang] Change artifactId to commons-lang3 for trunk...

Ok, just wanted to make sure I wasn't off base here. Want me to commit it (it's change on my local)? On Thu, Jul 22, 2010 at 2:52 PM, Paul Benedict wrote: > +1. One goal that Henri and I believed in is side-by-side / casual migration > of code. You can't do that with the same artifactId. > > On

Re: [lang] Change artifactId to commons-lang3 for trunk...

+1. One goal that Henri and I believed in is side-by-side / casual migration of code. You can't do that with the same artifactId. On Thu, Jul 22, 2010 at 1:50 PM, James Carman wrote: > All, > > Changing the package name helps, but I think we need to also change > the artifactId so that when folks

[lang] Change artifactId to commons-lang3 for trunk...

All, Changing the package name helps, but I think we need to also change the artifactId so that when folks are using maven, they can have both lang3 and older versions on the classpath at the same time. Thoughts? Thanks, James ---

Re: [VOTE] Release Commons Lang 3.0 Beta.1

Yes, that's what we're (so far Matt and me) suggesting. There's no need for an abstract superclass here. On Thu, Jul 22, 2010 at 2:34 PM, Paul Benedict wrote: > Sorry about "no-op" implementation.. I meant default implementation. I > believe a worthy goal would be to use EventListenerSupport out

Re: [VOTE] Release Commons Lang 3.0 Beta.1

I've been talking it over with James and we've considered the option of swapping the inheritance chain so that there is an EventListenerSource class that extends EventListenerSupport but includes the "source" property and documentation on how to write subclasses as described in the AbstractEventSup

Re: [VOTE] Release Commons Lang 3.0 Beta.1

Sorry about "no-op" implementation.. I meant default implementation. I believe a worthy goal would be to use EventListenerSupport out of the box, if possible, and allow subclassing for further customization. On Thu, Jul 22, 2010 at 1:29 PM, James Carman wrote: > I think we're leaning toward just

Re: [VOTE] Release Commons Lang 3.0 Beta.1

I think we're leaning toward just having EventListenerSupport. On Thu, Jul 22, 2010 at 2:27 PM, Paul Benedict wrote: > I have a philosophical problem with EventListenerSupport extending > AbstractEventSupport. I look at the class names, and I ask what does the > concrete class do that AbstractEve

Re: [VOTE] Release Commons Lang 3.0 Beta.1

I have a philosophical problem with EventListenerSupport extending AbstractEventSupport. I look at the class names, and I ask what does the concrete class do that AbstractEventSupport doesn't? I say either provide one abstract class, or one concrete class, but not both. On Thu, Jul 22, 2010 at 1:2

Re: [VOTE] Release Commons Lang 3.0 Beta.1

Paul: As of now there are two options. The first is to remove AbstractEventSupport in favor of EventListenerSupport. The second is for EventListenerSupport to extend AbstractEventSupport. -Matt On Jul 22, 2010, at 1:21 PM, Paul Benedict wrote: > I looked at both in SVN and see convergence a

Re: [VOTE] Release Commons Lang 3.0 Beta.1

That's what this discussion is all about. I added mine in so we could discuss and come up with a gameplan to move forward. On Thu, Jul 22, 2010 at 2:21 PM, Paul Benedict wrote: > I looked at both in SVN and see convergence and not too much difference. Can > you guys agree to removing one? Which

Re: [VOTE] Release Commons Lang 3.0 Beta.1

I looked at both in SVN and see convergence and not too much difference. Can you guys agree to removing one? Which one? I know the classes are not identical, but they are similar enough to go "hmmm". On Thu, Jul 22, 2010 at 1:17 PM, Matt Benson wrote: > > On Jul 22, 2010, at 1:11 PM, Paul Benedi

Re: [VOTE] Release Commons Lang 3.0 Beta.1

On Thu, Jul 22, 2010 at 2:11 PM, Paul Benedict wrote: > Does EventListenerSupport provide anything useful besides a no-op > implementation? > No-op? Where do you see a no-op? - To unsubscribe, e-mail: dev-unsubscr...@commons.ap

Re: [VOTE] Release Commons Lang 3.0 Beta.1

On Jul 22, 2010, at 1:11 PM, Paul Benedict wrote: > Does EventListenerSupport provide anything useful besides a no-op > implementation? > EventListenerSupport does. AbstractEventSupport IMO provides little over ELS: an Object event source, which in my experience is not necessarily the greate

Re: [VOTE] Release Commons Lang 3.0 Beta.1

Does EventListenerSupport provide anything useful besides a no-op implementation? On Thu, Jul 22, 2010 at 12:49 PM, James Carman wrote: > On Thu, Jul 22, 2010 at 1:43 PM, Matt Benson wrote: > > > > My point was that one could just as easily add these methods to a > subclass of EventListenerSuppo

Re: [VOTE] Release Commons Lang 3.0 Beta.1

On Thu, Jul 22, 2010 at 1:43 PM, Matt Benson wrote: > > My point was that one could just as easily add these methods to a subclass of > EventListenerSupport.  :) > +1, agree with Matt here. Why not just extend EventListenerSupport and add your custom fire* methods there? But, if you don't want

Re: [VOTE] Release Commons Lang 3.0 Beta.1

On Thu, Jul 22, 2010 at 1:43 PM, Matt Benson wrote: >> What is the usecase for the EventSupport interface?  Unit testing? >> > > James, >  Of all people I shouldn't have to tell you that one usecase is proxying.  ;P > How do I make an emoticon that sticks out a bigger tongue!?!?! :)

Re: [VOTE] Release Commons Lang 3.0 Beta.1

On Jul 22, 2010, at 12:41 PM, Michael Wooten wrote: > Matt, > > Technically the AbstractEventSupport class itself doesn't add that > much value. It is meant more as a utility for someone providing their > own listeners and events. It is just one of those classes I've > rewritten on many projects

Re: [VOTE] Release Commons Lang 3.0 Beta.1

On Jul 22, 2010, at 12:34 PM, James Carman wrote: > On Thu, Jul 22, 2010 at 12:44 PM, Michael Wooten > wrote: >> I personally believe that there is a benefit for the EventSupport >> interface, even if it can only register one type of listener. I also >> believe that AbstractEventSupport could b

Re: [VOTE] Release Commons Lang 3.0 Beta.1

Matt, Technically the AbstractEventSupport class itself doesn't add that much value. It is meant more as a utility for someone providing their own listeners and events. It is just one of those classes I've rewritten on many projects that I work on. The benefit of extending AbstractEventSupport ov

Re: [VOTE] Release Commons Lang 3.0 Beta.1

On Thu, Jul 22, 2010 at 12:44 PM, Michael Wooten wrote: > I personally believe that there is a benefit for the EventSupport > interface, even if it can only register one type of listener. I also > believe that AbstractEventSupport could be very useful. What is the usecase for the EventSupport int

Re: [VOTE] Release Commons Lang 3.0 Beta.1

On Jul 22, 2010, at 11:44 AM, Michael Wooten wrote: > All, > > Since I started this mess with LANG-580 I figured I would chime in. > > I personally believe that there is a benefit for the EventSupport > interface, even if it can only register one type of listener. Silly me; I was talking as t

Re: [VOTE] Release Commons Lang 3.0 Beta.1

All, Since I started this mess with LANG-580 I figured I would chime in. I personally believe that there is a benefit for the EventSupport interface, even if it can only register one type of listener. I also believe that AbstractEventSupport could be very useful. It basically provides an abstract

Re: [LANG] EventUtils and EventListenerSupport...

James, I really like your implementation of the EventListenerSupport class. I think there is still a case for the EventSupport interface and the AbstractEventSupport class, but your EventListenerSupport class definitely deprecates the ReflectiveEventSupport class from LANG-580. I have created a ne

RE: OS400FTPEntryParser Fix

Or we should turn it into an ivar that can be set... Gary Gregory Senior Software Engineer Seagull Software email: ggreg...@seagullsoftware.com email: ggreg...@apache.org www.seagullsoftware.com > -Original Message- > From: Big Jim [mailto:big...@speakeasy.net] > Sent: Thursday, July 2

OS400FTPEntryParser Fix

I have discovered a bug in org.apache.commons.net.ftp.parser.OS400FTPEntryParser.java. The variable "private static final String DEFAULT_DATE_FORMAT" needs to be changed from "yy/MM/dd HH:mm:ss"; //01/11/09 12:30:24 to "MM/dd/yy HH:mm:ss"; //01/15/08 14:21:38 to work correctly. I have tested

Re: [VOTE] Release Commons Lang 3.0 Beta.1

On Jul 22, 2010, at 10:08 AM, James Carman wrote: > On Thu, Jul 22, 2010 at 11:02 AM, Matt Benson wrote: >> I like the compiler-checked aspect of your code, James, considering it >> scratches an itch reminiscent of my current work in [proxy]. I'm happy for >> your code to survive this POE. >>

Re: [VOTE] Release Commons Lang 3.0 Beta.1

On Thu, Jul 22, 2010 at 11:02 AM, Matt Benson wrote: > I like the compiler-checked aspect of your code, James, considering it > scratches an itch reminiscent of my current work in [proxy].  I'm happy for > your code to survive this POE. > I think it reads very well, too. The fire() method used

Re: clirr for MATH-389

> > Concerning the items related to this issue: > > > > 3rd item: The method is declared in a superclass. > > 4th item: The constant is defined in a superclass. It is still "public" but > > I think that it's a mistake and should be made "private" instead. > > No, it was intentional so users can e

Re: [VOTE] Release Commons Lang 3.0 Beta.1

On Jul 22, 2010, at 8:43 AM, James Carman wrote: > I'm going to vote -1 on this one until we figure out what to do with > the LANG-580 stuff. I committed my event support stuff and I think it > is a better implementation. I would rather not release a beta with > the other event stuff in there i

Re: [VOTE] Release Commons Lang 3.0 Beta.1

I'm going to vote -1 on this one until we figure out what to do with the LANG-580 stuff. I committed my event support stuff and I think it is a better implementation. I would rather not release a beta with the other event stuff in there if we're going to go with my stuff. If you guys don't like

Re: clirr for MATH-389

On 22 July 2010 13:11, Luc Maisonobe wrote: > Le 22/07/2010 12:46, Gilles Sadowski a écrit : >> Hi. >> >>> Luc Maisonobe commented on MATH-389: >>> >>> >>> At first sight, it seems good to me. >>> You can check there are incomatibilities by performing the chang

Re: clirr for MATH-389

Le 22/07/2010 12:46, Gilles Sadowski a écrit : > Hi. > >> Luc Maisonobe commented on MATH-389: >> >> >> At first sight, it seems good to me. >> You can check there are incomatibilities by performing the changes locally >> and run "clirr" (for example by runnin

Re: svn commit: r966589 - in /commons/proper/lang/trunk/src: main/java/org/apache/commons/lang3/event/ test/java/org/apache/commons/lang3/event/

I believe I just fixed this. I need to configure that system-wide for .java files. On Thu, Jul 22, 2010 at 8:02 AM, sebb wrote: > On 22 July 2010 12:35,   wrote: >> Author: jcarman >> Date: Thu Jul 22 11:35:07 2010 >> New Revision: 966589 >> >> URL: http://svn.apache.org/viewvc?rev=966589&view=r

Re: svn commit: r966589 - in /commons/proper/lang/trunk/src: main/java/org/apache/commons/lang3/event/ test/java/org/apache/commons/lang3/event/

On 22 July 2010 12:35, wrote: > Author: jcarman > Date: Thu Jul 22 11:35:07 2010 > New Revision: 966589 > > URL: http://svn.apache.org/viewvc?rev=966589&view=rev > Log: > Misc. event utils. > > Added: >     > commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/event/EventListenerSupp

[LANG] EventUtils and EventListenerSupport...

All, I have committed two new classes into the "event" package in trunk. 1. EventListenerSupport - my implementation of an event listener support class. The idea is that this would replace the recently-committed stuff from LANG-580. 2. EventUtils - a static "utils" class which has a couple of

clirr for MATH-389

Hi. > Luc Maisonobe commented on MATH-389: > > > At first sight, it seems good to me. > You can check there are incomatibilities by performing the changes locally > and run "clirr" (for example by running "mvn site") and check the clirr > report. Here is th