We have 3 +1's from Mark, Luc and Mladen
Thus the vote passed. I'll push the sources
and create an ANN later today.
Regards
--
^TM
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: de
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-proxy-test has an issue affecting its community integration.
This
On 13 February 2012 02:01, sebb wrote:
> On 12 February 2012 16:09, Gary Gregory wrote:
>> Hi Sebb,
>>
>> Sorry, -1: I get a build failure with my default set up using
>> https://repository.apache.org/content/repositories/orgapachecommons-218/commons-net/commons-net/3.1/
>> *commons-net-3.1-src.z
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-digester3 has an issue affecting its community integration.
This i
On 12 February 2012 20:42, Oliver Heger wrote:
> Hi,
>
> same problem with site generation here.
>
> In addition to Gary's findings I just noticed a very minor detail: The
> Built-By header in the manifest does not contain the actual user name, but
> just the text 'User'. Was this intended?
No, I
On 12 February 2012 16:09, Gary Gregory wrote:
> Hi Sebb,
>
> Sorry, -1: I get a build failure with my default set up using
> https://repository.apache.org/content/repositories/orgapachecommons-218/commons-net/commons-net/3.1/
> *commons-net-3.1-src.zip*. The checkstyle XML files are missing.
>
>
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-email has an issue affecting its community integration.
This issue
2012/2/13 Mark Thomas :
>
> General
> - Logging in pool, if any, should be minimal
>
Two general questions:
When there are several pools,
- is it possible to discern log messages from different pools?
- is it possible to control logging level for a single pool, or all
pools have the same logging c
Thanks to all who contributed to this thread. I thought it might be
useful to summarize the discussion so far.
Preferences have been expressed for:
- java.util.logging (jul)
- commons logging (cl)
- SLF4J
General
- Logging in pool, if any, should be minimal
jul
- Anything other than jul adds a
Hi Simone,
the patch you mentioned was something I would have asked you, before or later :P
I know I can read your mind :)
Since we are on topic: is there any particular reason why Zero.zero()
can not be part of Semigroup interface? Or better: is there any
benefit we can get from keeping Zer
Hola Claudio,
the patch you mentioned was something I would have asked you, before or later :P
Since we are on topic: is there any particular reason why Zero.zero()
can not be part of Semigroup interface? Or better: is there any
benefit we can get from keeping Zero and Semigroup separated?
TIA,
Hi,
* the mapping between primitive types and their respective default
*Operations is known and kept somewhere (abstract class, etc);
* each algorithm specifies only once the set of primitive types that
it accepts;
* with a bit of magic (?) we combine the above to provide shortcuts to
t
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=18732&projectId=75
Build statistics:
State: Failed
Previous State: Ok
Started at: Sun 12 Feb 2012 21:40:59 +
Finished at: Sun 12 Feb 2012 21:41:43 +
Total time: 44s
Build Trigger: Schedule
Build N
Hi *,
while the idea is fine, it is not clear to me how you intend
implementing it. Please fill an issue and attach a patch so we can
discuss also about the "how" and not only "what" :)
best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/
Hi Bene,
>
>
> yes I did (as I said ;-). So I guess, that we can implement it the way I
> said, but make sure Maps will be handled the way they were in BeanUtils1.
>
that would be acceptable since users are already used to that behavior
>
> Any thoughts about what James suggested? Just having to
Hi guys,
> * the mapping between primitive types and their respective default
> *Operations is known and kept somewhere (abstract class, etc);
> * each algorithm specifies only once the set of primitive types that
> it accepts;
> * with a bit of magic (?) we combine the above to provide shortc
Am 12.02.2012 18:28, schrieb Simone Tripodi:
Hi Bene,
Hi!
[...]
copyProperties() can be implemented likewise. Is that really all we have to
do, or am I missing something? I've looked at BeanUtils1 and they are
handling Maps a little differently by coping all entries. So I guess we have
to
Hi,
same problem with site generation here.
In addition to Gary's findings I just noticed a very minor detail: The
Built-By header in the manifest does not contain the actual user name,
but just the text 'User'. Was this intended?
Oliver
Am 12.02.2012 17:09, schrieb Gary Gregory:
Hi Sebb,
Hi Simone,
Would it be so terrible to maintain such redundancy?
IMHO, yes, because:
* it has to be applied in each class of algorithms we support;
* switching to proposed APIs, would proliferate that APIs in each algorithm;
* weight types are driven by generics, so users cannot bind wr
Hola,
> Would it be so terrible to maintain such redundancy?
IMHO, yes, because:
* it has to be applied in each class of algorithms we support;
* switching to proposed APIs, would proliferate that APIs in each algorithm;
* weight types are driven by generics, so users cannot bind wrong
weig
Hi Bene,
>
> public B cloneBean()
> throws aLotOfExceptions ;-)
> {
> @SuppressWarnings( "unchecked" )
> B clone = (B) bean.getClass().newInstance();
> DefaultBeanAccessor cloneAccessor = new DefaultBeanAccessor( clone
> );
> cloneAccessor.populate( this.describe() );
> return cl
Hello Marco,
I understand and agree with you about your doubts - I don't have a
strong idea, anyway I wouldn't take the *Handler as first choice,
since it does not drive users to an event-handler alike programming
model, rather *Operations makes more sense...
+1
c00l :)
Furthermore I think
Hi Sebb,
Sorry, -1: I get a build failure with my default set up using
https://repository.apache.org/content/repositories/orgapachecommons-218/commons-net/commons-net/3.1/
*commons-net-3.1-src.zip*. The checkstyle XML files are missing.
Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
Mave
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-digester3 has an issue affecting its community integration.
This i
If we jump to java 7, we can clean up our exceptions by using
ReflectiveOperationException.
Sent from tablet device. Please excuse typos and brevity.
On Feb 12, 2012 6:28 AM, "Benedikt Ritter" wrote:
> Hi,
>
> now that we have implemented describe() and populate() on
> DefaultBeanAccessor, clon
Hi,
now that we have implemented describe() and populate() on
DefaultBeanAccessor, cloneBean() and copyProperties(T target) seem very
easy to implement. I would realize cloneBean() simply like:
public B cloneBean()
throws aLotOfExceptions ;-)
{
@SuppressWarnings( "unchecked" )
B c
Hi all,
> I understand and agree with you about your doubts - I don't have a
> strong idea, anyway I wouldn't take the *Handler as first choice,
> since it does not drive users to an event-handler alike programming
> model, rather *Operations makes more sense...
+1
Furthermore I think that nam
27 matches
Mail list logo
