Luc Maisonobe wrote:
> Le 24/07/2010 04:41, Bill Barker a écrit :
>>
>> --
>> From: "Phil Steitz"
>> Sent: Friday, July 23, 2010 5:42 PM
>> To: "Commons Developers List"
>> Subject: Re: clirr for MATH-389
>>
>>> Gilles Sadowski wrote:
Inten
- "Phil Steitz" a écrit :
> Luc Maisonobe wrote:
> > Le 24/07/2010 04:41, Bill Barker a écrit :
> >>
> >> --
> >> From: "Phil Steitz"
> >> Sent: Friday, July 23, 2010 5:42 PM
> >> To: "Commons Developers List"
> >> Subject: Re: clirr for MATH
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-jelly-tags-jaxme has an issue affecting its community
integration
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-jelly-tags-xml-test has an issue affecting its community
integrat
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
+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
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
A couple of things I noticed.
1) In the JavaDocs section of the developer guide
(http://people.apache.org/~bayard/commons-lang-3.0-beta-3/site/developerguide.html)
it states that IllegalArgumentException should always be thrown
instead of NullPointerException. However, changes for version 3.0 to
t
+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
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
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
Le 26/07/2010 14:17, er...@apache.org a écrit :
> Author: erans
> Date: Mon Jul 26 12:17:45 2010
> New Revision: 979257
>
> URL: http://svn.apache.org/viewvc?rev=979257&view=rev
> Log:
> Fixed bugs in "BrentOptimizer".
> Renamed "BrentMinimizerTest" to "BrentOptimizerTest".
> Modified "MultiStartU
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
+1
Oliver
Am 26.07.2010 08:40, schrieb Henri Yandell:
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.
Update from Beta-1:
-
> > * Implements Richard Brent's algorithm (from his book "Algorithms for
> > * Minimization without Derivatives", p. 79) for finding minima of real
> > - * univariate functions.
> > + * univariate functions. This implementation is an adaptation partly
> > + * based on the Python code from SciP
Le 26/07/2010 22:38, Gilles Sadowski a écrit :
>>> * Implements Richard Brent's algorithm (from his book "Algorithms for
>>> * Minimization without Derivatives", p. 79) for finding minima of real
>>> - * univariate functions.
>>> + * univariate functions. This implementation is an adaptation pa
Now that our parent POM is mostly Nexus-friendly, can we declare a snapshot
policy? IMO, it should be permissible for any committer to publish a snapshot
from an unblemished trunk at any time. Let's say that a lack of dissent will
make this quasi-official. :)
-Matt
--
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=376449&projectId=21
Build statistics:
State: Ok
Previous State: Failed
Started at: Mon 26 Jul 2010 05:45:53 -0700
Finished at: Mon 26 Jul 2010 05:47:31 -0700
Total time: 1m 38s
Build Trigger: Schedule
Bui
We can't have Continuum/Hudson publishing the snapshots? :)
On Mon, Jul 26, 2010 at 4:15 PM, Matt Benson wrote:
> Now that our parent POM is mostly Nexus-friendly, can we declare a snapshot
> policy? IMO, it should be permissible for any committer to publish a
> snapshot from an unblemished tr
That is what Mahout has been doing for some time. Makes it very nice to
have a snapshot release available in maven.
On Mon, Jul 26, 2010 at 8:27 PM, Henri Yandell wrote:
> We can't have Continuum/Hudson publishing the snapshots? :)
>
> On Mon, Jul 26, 2010 at 4:15 PM, Matt Benson wrote:
> > No
Le 27/07/2010 05:27, Henri Yandell a écrit :
We can't have Continuum/Hudson publishing the snapshots? :)
+1000 ! :)
smime.p7s
Description: S/MIME Cryptographic Signature
21 matches
Mail list logo
