On 2 June 2011 22:32, Niall Pemberton wrote:
> On Thu, Jun 2, 2011 at 10:24 PM, Nick Burch wrote:
>> On Thu, 2 Jun 2011, Niall Pemberton wrote:
>>>
>>> If you use the Maven2 build then it should all build as expected.
>>
>> So it seems. I think I'll remove the release target from the ant build (s
On Thu, Jun 2, 2011 at 10:24 PM, Nick Burch wrote:
> On Thu, 2 Jun 2011, Niall Pemberton wrote:
>>
>> If you use the Maven2 build then it should all build as expected.
>
> So it seems. I think I'll remove the release target from the ant build (so
> no-one else tries it and gets bitten), then see i
On 6/2/11 2:24 PM, Nick Burch wrote:
> On Thu, 2 Jun 2011, Niall Pemberton wrote:
>> If you use the Maven2 build then it should all build as expected.
>
> So it seems. I think I'll remove the release target from the ant
> build (so no-one else tries it and gets bitten), then see if I can
> figure o
On Thu, 2 Jun 2011, Niall Pemberton wrote:
If you use the Maven2 build then it should all build as expected.
So it seems. I think I'll remove the release target from the ant build (so
no-one else tries it and gets bitten), then see if I can figure out how to
use the maven release plugin!
Ni
On Thu, Jun 2, 2011 at 6:36 PM, Nick Burch wrote:
> On Thu, 2 Jun 2011, Oliver Heger wrote:
>>
>> About the distribution files: Shouldn't the naming be
>> commons-validator-1.4.0-beta1 rather than validator-1.4.0-beta1? Also the
>> manifest of the jar in the binary distribution does not contain al
On 6/2/11 12:04 PM, Oliver Heger wrote:
> Am 02.06.2011 19:36, schrieb Nick Burch:
>> On Thu, 2 Jun 2011, Oliver Heger wrote:
>>> About the distribution files: Shouldn't the naming be
>>> commons-validator-1.4.0-beta1 rather than validator-1.4.0-beta1?
>>> Also
>>> the manifest of the jar in the bi
FYI.
They had a bunch of Commons libraries listed; generally we did very
well and had 0 issues.
-- Forwarded message --
From: Kamani, Sejal Pranlal
Date: Thu, Jun 2, 2011 at 9:33 AM
Subject: Fortify Open Review
To: "openau...@fortifysoftware.com"
Dear Fortify Open Review Users
This is a vote to release Apache Commons NET 3.0.1 based on RC3.
Very little has changed since 3.0; the release is being made to
correct a regression in the FTPClient storeFile method.
[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because...
tag: http://svn.apache.o
Am 02.06.2011 19:36, schrieb Nick Burch:
On Thu, 2 Jun 2011, Oliver Heger wrote:
About the distribution files: Shouldn't the naming be
commons-validator-1.4.0-beta1 rather than validator-1.4.0-beta1? Also
the manifest of the jar in the binary distribution does not contain
all properties typical
On 2 June 2011 18:24, Jörg Schaible wrote:
> Nick Burch wrote:
>
>> Hi All
>>
>> Following last week's discussions, I've rolled a RC for Commons Validator
>> 1.4 beta 1. The idea of this release is to get some wider testing of the
>> codebase, owing to the 4.5 year gap since 1.3.1, before we hopef
On Thu, 2 Jun 2011, Oliver Heger wrote:
About the distribution files: Shouldn't the naming be
commons-validator-1.4.0-beta1 rather than validator-1.4.0-beta1? Also
the manifest of the jar in the binary distribution does not contain all
properties typical for commons components. When I build the
Nick Burch wrote:
> Hi All
>
> Following last week's discussions, I've rolled a RC for Commons Validator
> 1.4 beta 1. The idea of this release is to get some wider testing of the
> codebase, owing to the 4.5 year gap since 1.3.1, before we hopefully
> release 1.4 in a few weeks time.
>
> (We be
Hi,
I don't know the code base either so will only give some technical
comments related to the artifacts:
Maven and ant builds work fine with Java 1.5 and 1.6 on Windows 7.
About the distribution files: Shouldn't the naming be
commons-validator-1.4.0-beta1 rather than validator-1.4.0-beta1?
Agreed. Memory is too constraining, I use a custom UnitFormatUtils class for
file sizes, time elapsed, and so on.
UnitFormatUtils has methods like:
/**
* Returns the given value in the format: value bytes(s).
*
* For example:
*
* 0 bytes
* 1 byte
* 2 bytes
On Thu, Jun 2, 2011 at 11:12 AM, Matt Benson wrote:
> Implying that "memory" is an overly constraining concept to apply here.
>
Technically a buffer is typically in memory, so the concept still fits
for that usecase. ;p However, I've actually used my toString() method
when logging the size of fi
On Thu, Jun 2, 2011 at 10:09 AM, Mark Thomas wrote:
> On 02/06/2011 16:06, James Carman wrote:
>> On Thu, Jun 2, 2011 at 11:03 AM, Matt Benson wrote:
>>>
>>> If our main concepts are parse/format, maybe what we are discussing is
>>> actually a specialized NumberFormat subclass.
>>>
>>
>> Agreed t
Thanks a lot Seb, much more than appreciated :)
Going to try it now and re-uploading the report!
All the best,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Thu, Jun 2, 2011 at 1:25 PM, sebb wrote:
> On 2 June 2011 08:13, Simone Tripodi wrote:
>> Hi Rahul,
>> I forgo
On 02/06/2011 16:06, James Carman wrote:
> On Thu, Jun 2, 2011 at 11:03 AM, Matt Benson wrote:
>>
>> If our main concepts are parse/format, maybe what we are discussing is
>> actually a specialized NumberFormat subclass.
>>
>
> Agreed that it does make sense as a number formatter. However, we
>
On Thu, Jun 2, 2011 at 11:03 AM, Matt Benson wrote:
>
> If our main concepts are parse/format, maybe what we are discussing is
> actually a specialized NumberFormat subclass.
>
Agreed that it does make sense as a number formatter. However, we
have to ask ourselves "where would a user most likely
On Thu, Jun 2, 2011 at 10:00 AM, James Carman
wrote:
> On Thu, Jun 2, 2011 at 10:54 AM, Stephen Colebourne
> wrote:
>> I'd say creating a new class for one method is a bad idea. HumanUtils
>> might work, although it could scope creep.
>>
>
> That's kind of why I suggested the other method! :)
>
On Thu, Jun 2, 2011 at 10:59 AM, Gary Gregory wrote:
>
> I was thinking that the class would also contain at least one toString
> method, for example toString(1000, MemoryUnit.BYTES) where MemoryUnit is an
> Enum. Useful for logging.
>
That's exactly where I use it, in my logging API. I like you
On Thu, Jun 2, 2011 at 10:54 AM, Stephen Colebourne
wrote:
> I'd say creating a new class for one method is a bad idea. HumanUtils
> might work, although it could scope creep.
>
That's kind of why I suggested the other method! :)
--
On Thu, Jun 2, 2011 at 10:54 AM, Stephen Colebourne wrote:
> I'd say creating a new class for one method is a bad idea. HumanUtils
> might work, although it could scope creep.
>
> Best approach is to try and think of other similar utilities, ie. look in
> Ant.
>
I was thinking that the class woul
I'd say creating a new class for one method is a bad idea. HumanUtils
might work, although it could scope creep.
Best approach is to try and think of other similar utilities, ie. look in Ant.
Stephen
On 2 June 2011 15:52, Gary Gregory wrote:
> On Thu, Jun 2, 2011 at 10:50 AM, James Carman
> w
On Thu, Jun 2, 2011 at 10:50 AM, James Carman wrote:
> On Thu, Jun 2, 2011 at 10:31 AM, Matt Benson wrote:
> > FWIW, this type of code lives in Ant as long
> > org.apache.tools.ant.util.StringUtils#parseHumanSizes(String). IMO it
> > would be fine to copy/adapt this method into lang3 in perhaps
On Thu, Jun 2, 2011 at 10:31 AM, Matt Benson wrote:
> FWIW, this type of code lives in Ant as long
> org.apache.tools.ant.util.StringUtils#parseHumanSizes(String). IMO it
> would be fine to copy/adapt this method into lang3 in perhaps
> StringUtils or NumberUtils. No harm in creating MemUtils as
FWIW, this type of code lives in Ant as long
org.apache.tools.ant.util.StringUtils#parseHumanSizes(String). IMO it
would be fine to copy/adapt this method into lang3 in perhaps
StringUtils or NumberUtils. No harm in creating MemUtils as James
suggested, but unless we can think of other things to
On Thu, Jun 2, 2011 at 10:01 AM, sebb wrote:
> On 2 June 2011 14:53, Gary Gregory wrote:
> > Or [cli]?
>
> Could be useful in property files as well, so I don't think CLI is
> appropriate.
>
> Ok, that makes sense.
Gary
> > would this be a new class?
>
> If necessary.
>
> > Or more an additio
On 2 June 2011 14:53, Gary Gregory wrote:
> Or [cli]?
Could be useful in property files as well, so I don't think CLI is appropriate.
> would this be a new class?
If necessary.
> Or more an additional parseMemSize Boolean param?
???
> Gary
>
> On Jun 2, 2011, at 9:48, sebb wrote:
>
>> A mai
On Thu, Jun 2, 2011 at 9:55 AM, sebb wrote:
>
> They specifically wanted Tomcat to support the suffices k and m that
> can be used when providing memory sizes to the Java -Xmx etc options.
>
> So yes, I guess the multiplier is 1024 here.
>
So, perhaps a MemUtils class? And perhaps a method like:
On 2 June 2011 14:50, James Carman wrote:
> What do they want? A method that returns the number of bytes? So, I
> suppose they would be multiplying by 1024 as opposed to 1000? So, 1k
> = 1024 bytes.
They specifically wanted Tomcat to support the suffices k and m that
can be used when providing
Or [cli]? would this be a new class? Or more an additional
parseMemSize Boolean param?
Gary
On Jun 2, 2011, at 9:48, sebb wrote:
> A mail on the Tomcat user list asked why Tomcat does not support
> shorthand suffices such as k & m when providing memory sizes, as is
> done by the the Java -Xms e
What do they want? A method that returns the number of bytes? So, I
suppose they would be multiplying by 1024 as opposed to 1000? So, 1k
= 1024 bytes.
On Thu, Jun 2, 2011 at 9:47 AM, sebb wrote:
> A mail on the Tomcat user list asked why Tomcat does not support
> shorthand suffices such as k &
A mail on the Tomcat user list asked why Tomcat does not support
shorthand suffices such as k & m when providing memory sizes, as is
done by the the Java -Xms etc options.
Seems to me this might be a useful addition to Lang?
-
To
Dear all,
I've submitted recently some pieces of code relating to iterative linear
solvers (see JIRA MATH-581).
I vwould be grateful for any feedback you could provide. Should I go on
submitting new pieces of code, or do you think it will not fit in
commons-math?
Best,
Sébastien
On 2 June 2011 08:13, Simone Tripodi wrote:
> Hi Rahul,
> I forgot to notify you the clirr report[1] is now online,
> unfortunately is not really useful due to repackaging :(
See
https://issues.apache.org/jira/browse/VFS-344
for one way to allow comparison across packages
> I'll wait for more
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
Hi Rahul,
I forgot to notify you the clirr report[1] is now online,
unfortunately is not really useful due to repackaging :(
I'll wait for more feedbacks from you before calling a vote for the
merge - in the meanwhile I'll continue developing on Sandbox with the
aim to prepare the 3.0 release.
Have
38 matches
Mail list logo
