On 11/03/2008, Henri Yandell [EMAIL PROTECTED] wrote:
All the issues for 2.4 are done; seems like it's release time?
There are a few Findbugs errors that look easy to fix, e.g
Computation of average could overflow in
commons-lang-rw/src/java/org/apache/commons/langEntities.java line
On 10/03/2008, sebb [EMAIL PROTECTED] wrote:
On 10/03/2008, Rory Winston [EMAIL PROTECTED] wrote:
Hi Sebb
A couple of things:
1. Which tests are you referring to in your first point below?
testFeb29IfLeapYear(org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest)
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 [EMAIL PROTECTED]
Project commons-net has an issue affecting its community integration.
This issue affects
Seems to me it would be a lot better if the FTPFile entry was still
generated, but with a null date.
I agree.
In the past, commons net ftp has always been using strict parsing,
with the result that some files might have been missed. We have
also seen this on Solaris with certain devices which
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 [EMAIL PROTECTED]
Project commons-jelly-tags-jaxme has an issue affecting its community
integration.
This
Sebb/Martin
The lenient future dates flag just allows a window of +1 day in the
short timestamp, which if now(), will not be rolled back by a year.
This is to prevent dates slightly in the future being rolled back
inappropriately. You keep mentioning the +/- 6 month thing - the problem
is
On 11/03/2008, Rory Winston [EMAIL PROTECTED] wrote:
Sebb/Martin
Martin and I agree on wanting the parser to return an FTPFile rather
than null for the cases where the date (etc ?) does not parse OK. I
would like to see this go into the next release of NET 1.5 and 2.0; I
think this will avoid a
