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

This vote is for a beta release--there will most likely still be some changes before the final release. -Matt On Jul 30, 2010, at 11:31 AM, Honton, Charles wrote: > -1, Still desire patch for LANG-462 applied. > > > > chas > > > --

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

-1, Still desire patch for LANG-462 applied. chas

Re: [lang] EventListenerSupport type variable Re: [VOTE] Release Commons Lang 3.0 Beta.1

On Mon, Jul 26, 2010 at 2:13 PM, Matt Benson wrote: > I can't argue much, because my $work stuff indeed does have a listener > interface that does not extend EventListener... > I originally had mine set up that way and I think the version we have at work has it set up that way, but I changed it

Re: [lang] EventListenerSupport type variable Re: [VOTE] Release Commons Lang 3.0 Beta.1

On Jul 26, 2010, at 12:13 PM, James Carman wrote: > I wouldn't do it. Folks don't necessarily extend EventListener, > although they should. I think it's adding restriction without adding > too much value. If EventListener had some methods on it that we > depended on then that would be a differ

Re: [lang] EventListenerSupport type variable Re: [VOTE] Release Commons Lang 3.0 Beta.1

I wouldn't do it. Folks don't necessarily extend EventListener, although they should. I think it's adding restriction without adding too much value. If EventListener had some methods on it that we depended on then that would be a different story. On Mon, Jul 26, 2010 at 12:16 PM, Michael Wooten

Re: [lang] EventSupport interface WAS Re: [VOTE] Release Commons Lang 3.0 Beta.1

+1 agreed. I think that there is a usefulness in both cases Matt mentions. May I also suggest that the interface be named EventSource instead of EventSupport, so as to avoid confusion with the EventListenerSupport class and better identify the class as being a source of events. -Michael On Mon, J

[lang] EventSupport interface WAS Re: [VOTE] Release Commons Lang 3.0 Beta.1

I think adding the EventSupport interface still has value; as mentioned before, some type that needs to support > 1 listener type can still implement EventSupport and this is more valuable than having no interface whatsoever with which to manipulate the object's listeners. The primary differenc

Re: [lang] EventListenerSupport type variable Re: [VOTE] Release Commons Lang 3.0 Beta.1

+1 to restricting the type. On Mon, Jul 26, 2010 at 12:05 PM, Matt Benson wrote: > To try and get this whole subject put to bed, is anyone opposed to > restricting the bounds of EventListenerSupport's variable to EventListener>?  It's not strictly necessary, but without the restriction, > the

[lang] EventListenerSupport type variable Re: [VOTE] Release Commons Lang 3.0 Beta.1

To try and get this whole subject put to bed, is anyone opposed to restricting the bounds of EventListenerSupport's variable to ? It's not strictly necessary, but without the restriction, the listener semantics of the ELS class itself are completely superficial, in which case why wouldn't we

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: [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: [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: [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: [VOTE] Release Commons Lang 3.0 Beta.1

> -Original Message- > From: sebb [mailto:seb...@gmail.com] > Sent: Wednesday, July 21, 2010 03:58 > To: Commons Developers List > Subject: Re: [VOTE] Release Commons Lang 3.0 Beta.1 > > On 21 July 2010 01:01, Henri Yandell wrote: > > Context: > > >

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

On Wed, Jul 21, 2010 at 6:10 PM, Phil Steitz wrote: > Henri Yandell wrote: >> Context: >> >>   Releasing a beta version of the Lang 3.0 API for user feedback. >> There aren't any major API changes expected, unless the community >> raises them. The aim would be to _not_ put this in the Maven >> rep

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

Henri Yandell wrote: > Context: > > Releasing a beta version of the Lang 3.0 API for user feedback. > There aren't any major API changes expected, unless the community > raises them. The aim would be to _not_ put this in the Maven > repository. Why not push this to the maven repos? I assume it

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

Artifacts look good, build works for me on Windows 7 with a JDK 1.5. Build of the site fails due to the missing findbugs-exclude-filter.xml file. As I understand, the site will be reworked later, correct? BTW, if you want, I can write something about the concurrent package. What I find confus

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

Chas, First of all, HI! Long time no see. Anyway, it's still slated for 3.0. This beta release is not really intended for the general audiences to be using it in "production" (hence the beta). It's just a "give us feedback" release. So, I wouldn't worry that 462 won't make it in. Your patch

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

I would love to see Lang-462 included. Thanks, chas -Original Message- From: Henri Yandell [mailto:flame...@gmail.com] Sent: Tuesday, July 20, 2010 8:01 PM To: Commons Developers List Subject: [VOTE] Release Commons Lang 3.0 Beta.1

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

On Wed, Jul 21, 2010 at 8:31 AM, sebb wrote: > On 21 July 2010 16:12, Henri Yandell wrote: >> On Wed, Jul 21, 2010 at 4:10 AM, sebb wrote: >>> On 21 July 2010 12:02, James Carman wrote: On Wed, Jul 21, 2010 at 6:58 AM, sebb wrote: > > What is the licence for the Spring Framework c

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

On Wed, Jul 21, 2010 at 8:39 AM, sebb wrote: > On 21 July 2010 16:23, Henri Yandell wrote: >> Thanks for the feedback sebb; comments inline: >> >> On Wed, Jul 21, 2010 at 3:58 AM, sebb wrote: >>> On 21 July 2010 01:01, Henri Yandell wrote: Signed downloads:    http://people.apach

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

On 21 July 2010 16:23, Henri Yandell wrote: > Thanks for the feedback sebb; comments inline: > > On Wed, Jul 21, 2010 at 3:58 AM, sebb wrote: >> On 21 July 2010 01:01, Henri Yandell wrote: >>> Context: >>> >>>  Releasing a beta version of the Lang 3.0 API for user feedback. >>> There aren't any

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

> -Original Message- > From: Henri Yandell [mailto:flame...@gmail.com] > Sent: Wednesday, July 21, 2010 08:24 > To: Commons Developers List > Subject: Re: [VOTE] Release Commons Lang 3.0 Beta.1 > > Thanks for the feedback sebb; comments inline: > > On Wed, Ju

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

On 21 July 2010 16:12, Henri Yandell wrote: > On Wed, Jul 21, 2010 at 4:10 AM, sebb wrote: >> On 21 July 2010 12:02, James Carman wrote: >>> On Wed, Jul 21, 2010 at 6:58 AM, sebb wrote: What is the licence for the Spring Framework code mentioned in NOTICE? >>> >>> Spring is Apach

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

Thanks for the feedback sebb; comments inline: On Wed, Jul 21, 2010 at 3:58 AM, sebb wrote: > On 21 July 2010 01:01, Henri Yandell wrote: >> Context: >> >>  Releasing a beta version of the Lang 3.0 API for user feedback. >> There aren't any major API changes expected, unless the community >> rai

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

On Wed, Jul 21, 2010 at 4:10 AM, sebb wrote: > On 21 July 2010 12:02, James Carman wrote: >> On Wed, Jul 21, 2010 at 6:58 AM, sebb wrote: >>> >>> What is the licence for the Spring Framework code mentioned in NOTICE? >>> >> >> Spring is Apache License 2.0 > > OK, this needs to be documented in N

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

On 21 July 2010 12:02, James Carman wrote: > On Wed, Jul 21, 2010 at 6:58 AM, sebb wrote: >> >> What is the licence for the Spring Framework code mentioned in NOTICE? >> > > Spring is Apache License 2.0 OK, this needs to be documented in NOTICE or LICENSE. > > --

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

On Wed, Jul 21, 2010 at 6:58 AM, sebb wrote: > > What is the licence for the Spring Framework code mentioned in NOTICE? > Spring is Apache License 2.0 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional c

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

On 21 July 2010 01:01, Henri Yandell wrote: > Context: > >  Releasing a beta version of the Lang 3.0 API for user feedback. > There aren't any major API changes expected, unless the community > raises them. The aim would be to _not_ put this in the Maven > repository. > > SVN tag: > >    http://sv