[codec] Update for Java 7

2017-10-20 Thread Gary Gregory 
Now that Codec 1.11 is out, I propose we update from Java 6 to 7.

Gary

Re: [VOTE] Release Apache Commons Codec 1.11 from RC1

2017-10-20 Thread Gary Gregory 
This VOTE passes with four (4) binding +1s from:

Bruno P. Kinoshita
Oliver Heger
Pascal Schumacher
Gary Gregory

I'll start the release process with letting it out of Nexus.

Gary


On Tue, Oct 17, 2017 at 12:30 PM, Gary Gregory  wrote:

> Hi All,
>
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Codec 1.10 was released, so I would like to release
> Apache Commons Codec 1.11.
>
> Apache Commons Codec 1.11 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/codec at revision 22530
> Get it like this: svn co https://dist.apache.org/repos/
> dist/dev/commons/codec
>
> The tag is here:
> https://svn.apache.org/repos/asf/commons/proper/codec/tags/
> commons-codec-1.11-RC1 svn revision 1812411.
> The SVN revision is noted because SVN tags are not immutable.
> Get it like this: svn co https://svn.apache.org/repos/
> asf/commons/proper/codec/tags/commons-codec-1.11-RC1
>
> Maven artifacts are here:
> https://repository.apache.org/service/local/repositories/
> orgapachecommons-1280
>
> These are the artifacts and their SHA1 hashes:
>
> /commons-codec/commons-codec/1.11/commons-codec-1.11-javadoc.jar
> (SHA1: 978245f8bd06d70703fa3180554c62891500f97a)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-src.zip.asc
> (SHA1: e7ae399382030672890331dbf2a5e5014e1febec)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-tests.jar.asc
> (SHA1: 15c48130bfc257b9e668910a344168da97a535ed)
> /commons-codec/commons-codec/1.11/commons-codec-1.11.pom.asc
> (SHA1: 5c7c9df6b11c0a9efae0890ba9a3e4f6f85d74b0)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-sources.jar.asc
> (SHA1: c80656e5dd8e46341db814bcef89c03f821db6f8)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-bin.tar.gz
> (SHA1: 59cf4653ec88c4a9fb3b95ecd065ba5229788a5c)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-src.tar.gz
> (SHA1: 6ba24a55e5f8a8d7c9fdf28e8cb4edcc0fe44626)
> /commons-codec/commons-codec/1.11/commons-codec-1.11.pom
> (SHA1: 093ee1760aba62d6896d578bd7d247d0fa52f0e7)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-sources.jar
> (SHA1: bce4ba84fd527950e35040b20a991c63e90e2850)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-tests.jar
> (SHA1: 8a0430c3138ce4a23b0b6c7b7409df54bb76feb9)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-bin.zip
> (SHA1: 63e6cc02e648b7d46f50bf0c4d6ffcafeddf8d04)
> /commons-codec/commons-codec/1.11/commons-codec-1.11.jar
> (SHA1: 3acb4705652e16236558f0f4f2192cc33c3bd189)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-src.zip
> (SHA1: b45a09ea3711a9346c71d062e5f06935685db9fb)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-javadoc.jar.asc
> (SHA1: 5e7eb8e6e1e51017d6fc52eaec5ad67dcc2c9dce)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-test-sources.jar.asc
> (SHA1: 5f8c723bbcf08c8c4434a6731fe52d5e5cd9df9b)
> /commons-codec/commons-codec/1.11/commons-codec-1.11.jar.asc
> (SHA1: 42f6f623c1448aea511f4ee77d62d4b962f68450)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-test-sources.jar
> (SHA1: 67f923eb8f532cc8de6e30e7baad3de872ea49f8)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-bin.zip.asc
> (SHA1: fae75e01aa6492e4659d2140fadff2878984b5c0)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-bin.tar.gz.asc
> (SHA1: 3eac777bbd8527dd62ad53349a0eaa1d5a4cc830)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-src.tar.gz.asc
> (SHA1: d96909338df98272e81d9c4ea2b49f849e095ee8)
>
> I tested this RC using 'mvn clean verify' on Windows 10 (Version
> 10.0.15063) with Oracle Java 7, Oracle Java 8, Oracle Java 9 and IBM Java 8
> using Maven 3.5.0:
>
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
> 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_80\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
> => BUILD SUCCESS
>
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
> 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 1.8.0_144, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_144\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> => BUILD SUCCESS
>
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
> 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 1.8.0, vendor: IBM Corporation
> Java home: C:\eclipse\IBM-6.4.5\ibm_sdk80\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "x86", family: "windows"
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pwi3280sr4fp5-20170421_01(SR4 FP5))
> IBM J9 VM (build 2.8, JRE 1.8.0 Windows 10 x86-32

[GitHub] commons-text issue #70: partial automated migration to assertj

2017-10-20 Thread kinow 
Github user kinow commented on the issue:

https://github.com/apache/commons-text/pull/70
  
I thought we were using Java 8, but [text] is actually using Java 7. I 
thought there was some discussion around the minimum requirement for the latest 
version of assertj being Java 8? So I assume it's safe to start with 2.8.0 now, 
and bump up to 3.8.0 later when we upgrade do Java 8?


---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text issue #70: partial automated migration to assertj

2017-10-20 Thread kinow 
Github user kinow commented on the issue:

https://github.com/apache/commons-text/pull/70
  
Looks good to me. Given [text] is already on Java 8, I believe it's a good 
candidate to start using assertj.

>The script use only the most basic assertj assertions, so the full power 
is not evident.

Indeed. But I like this approach. We introduce assertj, migrate the old 
assertions, and only then we start replacing/simplifying parts of the tests. 
And new text code can also be written with assertj.


---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text issue #72: fix for TEXT-100

2017-10-20 Thread kinow 
Github user kinow commented on the issue:

https://github.com/apache/commons-text/pull/72
  
Merged, and ticket updated. Thanks for the pull request @drajakumar !


---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text pull request #72: fix for TEXT-100

2017-10-20 Thread asfgit 
Github user asfgit closed the pull request at:

https://github.com/apache/commons-text/pull/72


---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RDF] Commons release?

2017-10-20 Thread Aaron Coburn 
Hello,

I wanted to check in on the status of a 0.4.0 release of Commons RDF. It seems 
that all of the open PRs have been merged. Any idea on a timeframe for the next 
release?

Thanks,
Aaron

On 9/19/17, 5:58 PM, "Aaron Coburn"  wrote:

Sergio,

Thanks! The LDP server implementation is spread across quite a few 
repositories in this github organization: https://github.com/trellis-ldp 
(everything is Apache2 licensed), but the core abstractions are found in:

API: https://github.com/trellis-ldp/trellis-api
SPI: https://github.com/trellis-ldp/trellis-spi
HTTP layer: https://github.com/trellis-ldp/trellis-http

Most of the components have already been released to maven central, but I'm 
still working on a few of them (particularly the HTTP layer and the persistence 
layer).

The main difference between this and, say, Marmotta, is that this 
implementation is designed to scale horizontally. And by making use of 
Commons-RDF, the interfaces of this LDP server aren't tied to a particular RDF 
library implementation -- e.g. Jena or RDF4J -- though I do use Jena in the 
implementation code. I am also making significant use of ZooKeeper (Curator), 
Kafka and Beam.

Aaron

> On Sep 19, 2017, at 5:27 PM, Sergio Fernández  wrote:
> 
> Hi Aaron,
> 
> you're right, we have quite some things to release. But first I' d like to
> take a look to our backlog, because we have some open PRs. Hopefully I'll
> have some time later this week, at the latest on the weekend.
> 
> Just for curiosity, can you provide us a pointer to your Commons RDF-based
> LDP implementation?
> 
> Thanks.
> 
> Cheers,
> 
> 
> 
> On Mon, Sep 18, 2017 at 2:24 PM, Aaron Coburn  wrote:
> 
>> Hi!
>> 
>> The last release of commons-rdf was from last November, and there are 
some
>> nice features in the master branch that I would really like to use --
>> especially the improved OSGi support. It seems that there are a few
>> unresolved jira issues, such that this wouldn't be a 1.0 release, but 
even
>> a 0.4.0 release would be great.
>> 
>> As a little background, over the last several months I've built a server
>> implementation of the W3C Linked Data Platform in which commons-rdf
>> provides all of the core RDF abstractions.
>> 
>> Would it be possible to move forward with a release? I would be more than
>> happy to help out.
>> 
>> Thanks,
>> Aaron
>> 
>> acob...@apache.org
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 


?B�CB�?�?[��X��ܚX�K??K[XZ[?�??]�][��X��ܚX�P?��[[ۜ˘\?X�?K�ܙ�B��܈?Y??]?[ۘ[??��[X[�?�??K[XZ[?�??]�Z?[???��[[ۜ˘\?X�?K�ܙ�B

Re: [OT] Running builds on my Galaxy phone?

2017-10-20 Thread kenneth mcfarland 
That looks cool. I hope it doesn't go the way of the Ubuntu phone that was
able to dual boot Android and Ubuntu. Being able to unplug your phone and
turn it into a desktop was a pretty cool feature that they had.

On Oct 20, 2017 10:23 AM, "Gary Gregory"  wrote:

> Some day, maybe:
>
> https://www.theregister.co.uk/2017/10/19/samsung_linux_on_galaxy/
>
>
> Gary
>

Fwd: svn commit: r1812768 - /commons/proper/email/trunk/pom.xml

2017-10-20 Thread Gary Gregory 
Oops, my bad! Thank you Pascal.

Gary

-- Forwarded message --
From: 
Date: Fri, Oct 20, 2017 at 11:39 AM
Subject: svn commit: r1812768 - /commons/proper/email/trunk/pom.xml
To: comm...@commons.apache.org


Author: pascalschumacher
Date: Fri Oct 20 17:39:43 2017
New Revision: 1812768

URL: http://svn.apache.org/viewvc?rev=1812768=rev
Log:
Revert revision 1812758 "Update tests from Apache Commons IO 2.5 to 2.6."
because commons-io requires java 7 and commons-email only java 6.

Modified:
commons/proper/email/trunk/pom.xml

Modified: commons/proper/email/trunk/pom.xml
URL: http://svn.apache.org/viewvc/commons/proper/email/trunk/
pom.xml?rev=1812768=1812767=1812768=diff

==
--- commons/proper/email/trunk/pom.xml (original)
+++ commons/proper/email/trunk/pom.xml Fri Oct 20 17:39:43 2017
@@ -247,7 +247,7 @@
 
 commons-io
 commons-io
-2.6
+2.5
 test

[OT] Running builds on my Galaxy phone?

2017-10-20 Thread Gary Gregory 
Some day, maybe:

https://www.theregister.co.uk/2017/10/19/samsung_linux_on_galaxy/


Gary

Invitation to become an Apache Commons Committer

2017-10-20 Thread Gary Gregory 
Hello Mark,

On behalf of the Apache Commons Project Management Committee (PMC), I'd
like to invite you to become an Apache Commons Committer.

Would you be interested in accepting this invitation? Please let us know by
replying to all.

For more information on responsiblities and expectations, please read:

- The Guide for new committers:
http://www.apache.org/dev/new-committers-guide.html
- The Committers' FAQ: http://www.apache.org/dev/committers.html

Thank you for your contributions to Apache Commons.

Gary Gregory,
Apache Commons PMC Chair,
On behalf of the Apache Commons PMC.

Re: [IO] Update to Java 7

2017-10-20 Thread Gary Gregory 
Dang, some of my tooling a.k.a. my brain is not working right today!

Gary

On Fri, Oct 20, 2017 at 10:47 AM, Pascal Schumacher <
pascalschumac...@gmx.net> wrote:

> [IO-503] Update platform requirement to Java 7.
>
> https://github.com/apache/commons-io/commit/3733512df9b172e0
> fdcf6cb0bdb7bc76131f0c8f#diff-600376dffeb79835ede4a0b285078036
>
> Guess who commited it 1,5 years ago? ;)
>
>
> Am 20.10.2017 um 18:44 schrieb Gary Gregory:
>
>> Now that we just released Commons IO 2.6, I think it is time to update to
>> Java 7 and take advantage of whatever we can.
>>
>> Java 8? Well, one step at a time :-)
>>
>> Gary
>>
>>
>

Re: [VOTE] Release Apache Commons Codec 1.11 from RC1

2017-10-20 Thread Gary Gregory 
My +1

Gary

On Tue, Oct 17, 2017 at 12:30 PM, Gary Gregory  wrote:

> Hi All,
>
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Codec 1.10 was released, so I would like to release
> Apache Commons Codec 1.11.
>
> Apache Commons Codec 1.11 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/codec at revision 22530
> Get it like this: svn co https://dist.apache.org/repos/
> dist/dev/commons/codec
>
> The tag is here:
> https://svn.apache.org/repos/asf/commons/proper/codec/tags/
> commons-codec-1.11-RC1 svn revision 1812411.
> The SVN revision is noted because SVN tags are not immutable.
> Get it like this: svn co https://svn.apache.org/repos/
> asf/commons/proper/codec/tags/commons-codec-1.11-RC1
>
> Maven artifacts are here:
> https://repository.apache.org/service/local/repositories/
> orgapachecommons-1280
>
> These are the artifacts and their SHA1 hashes:
>
> /commons-codec/commons-codec/1.11/commons-codec-1.11-javadoc.jar
> (SHA1: 978245f8bd06d70703fa3180554c62891500f97a)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-src.zip.asc
> (SHA1: e7ae399382030672890331dbf2a5e5014e1febec)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-tests.jar.asc
> (SHA1: 15c48130bfc257b9e668910a344168da97a535ed)
> /commons-codec/commons-codec/1.11/commons-codec-1.11.pom.asc
> (SHA1: 5c7c9df6b11c0a9efae0890ba9a3e4f6f85d74b0)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-sources.jar.asc
> (SHA1: c80656e5dd8e46341db814bcef89c03f821db6f8)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-bin.tar.gz
> (SHA1: 59cf4653ec88c4a9fb3b95ecd065ba5229788a5c)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-src.tar.gz
> (SHA1: 6ba24a55e5f8a8d7c9fdf28e8cb4edcc0fe44626)
> /commons-codec/commons-codec/1.11/commons-codec-1.11.pom
> (SHA1: 093ee1760aba62d6896d578bd7d247d0fa52f0e7)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-sources.jar
> (SHA1: bce4ba84fd527950e35040b20a991c63e90e2850)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-tests.jar
> (SHA1: 8a0430c3138ce4a23b0b6c7b7409df54bb76feb9)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-bin.zip
> (SHA1: 63e6cc02e648b7d46f50bf0c4d6ffcafeddf8d04)
> /commons-codec/commons-codec/1.11/commons-codec-1.11.jar
> (SHA1: 3acb4705652e16236558f0f4f2192cc33c3bd189)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-src.zip
> (SHA1: b45a09ea3711a9346c71d062e5f06935685db9fb)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-javadoc.jar.asc
> (SHA1: 5e7eb8e6e1e51017d6fc52eaec5ad67dcc2c9dce)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-test-sources.jar.asc
> (SHA1: 5f8c723bbcf08c8c4434a6731fe52d5e5cd9df9b)
> /commons-codec/commons-codec/1.11/commons-codec-1.11.jar.asc
> (SHA1: 42f6f623c1448aea511f4ee77d62d4b962f68450)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-test-sources.jar
> (SHA1: 67f923eb8f532cc8de6e30e7baad3de872ea49f8)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-bin.zip.asc
> (SHA1: fae75e01aa6492e4659d2140fadff2878984b5c0)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-bin.tar.gz.asc
> (SHA1: 3eac777bbd8527dd62ad53349a0eaa1d5a4cc830)
> /commons-codec/commons-codec/1.11/commons-codec-1.11-src.tar.gz.asc
> (SHA1: d96909338df98272e81d9c4ea2b49f849e095ee8)
>
> I tested this RC using 'mvn clean verify' on Windows 10 (Version
> 10.0.15063) with Oracle Java 7, Oracle Java 8, Oracle Java 9 and IBM Java 8
> using Maven 3.5.0:
>
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
> 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_80\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
> => BUILD SUCCESS
>
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
> 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 1.8.0_144, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_144\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> => BUILD SUCCESS
>
> Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
> 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 1.8.0, vendor: IBM Corporation
> Java home: C:\eclipse\IBM-6.4.5\ibm_sdk80\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "x86", family: "windows"
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pwi3280sr4fp5-20170421_01(SR4 FP5))
> IBM J9 VM (build 2.8, JRE 1.8.0 Windows 10 x86-32 20170419_344392 (JIT
> enabled, AOT enabled)
> J9VM - R28_20170419_1004_B344392
> JIT  - tr.r14.java_20170419_344392
> GC   - R28_20170419_1004_B344392
> J9CL - 20170419_344392)
>

Re: [IO] Update to Java 7

2017-10-20 Thread Pascal Schumacher 

[IO-503] Update platform requirement to Java 7.

https://github.com/apache/commons-io/commit/3733512df9b172e0fdcf6cb0bdb7bc76131f0c8f#diff-600376dffeb79835ede4a0b285078036

Guess who commited it 1,5 years ago? ;)

Am 20.10.2017 um 18:44 schrieb Gary Gregory:

Now that we just released Commons IO 2.6, I think it is time to update to
Java 7 and take advantage of whatever we can.

Java 8? Well, one step at a time :-)

Gary

[IO] Update to Java 7

2017-10-20 Thread Gary Gregory 
Now that we just released Commons IO 2.6, I think it is time to update to
Java 7 and take advantage of whatever we can.

Java 8? Well, one step at a time :-)

Gary

[GitHub] commons-text issue #69: Fix typos, minor clean ups

2017-10-20 Thread PascalSchumacher 
Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-text/pull/69
  
typo issue fixed in: 
https://github.com/apache/commons-text/commit/804e4599bd63e4bb14c905613711eac8829e54fb

Thanks again for reporting!


---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text issue #69: Fix typos, minor clean ups

2017-10-20 Thread PascalSchumacher 
Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-text/pull/69
  
created https://issues.apache.org/jira/browse/TEXT-105 for the typo in 
`LongestCommonSubsequence#logestCommonSubsequence`.


---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[text] fix for TEXT-100

2017-10-20 Thread don jeba 

Hello,    The fix meant for the bug TEXT-100 is now available for review.

fix for TEXT-100 by drajakumar · Pull Request #72 · apache/commons-text

  
|  
|   
|   
|   ||

   |

  |
|  
||  
fix for TEXT-100 by drajakumar · Pull Request #72 · apache/commons-text
 commons-text - Mirror of Apache Commons Text  |   |

  |

  |

 


Can you kindly review and comment.
Thank you,
Regards,Don Jeba.

Re: Do we really need to read keepalive NOOP responses from FTP server?

2017-10-20 Thread Basin Ilya 
Hi Sebb

Here are my observations:

1)
When retrieving a file, FTP servers send the transfer status right after they 
send the EOF on the data socket, but before the client closes the socket.
This may lead to a race condition:
If we've sent a NOOP not longer than a second ago and want to consume the NOOP 
reply, we may receive the transfer status instead. Subsequent call to
completePendingCommand() will consume the NOOP reply.

Maybe it's not a big problem, because we will have either
226-File successfully transferred
or
200 NOOP command successful.
as our last message and a high-level FTPClient method will return true.


2) Pure-FTPd:

During a transmission Pure-FTPd replies to NOOPs immediately with:
500 Unknown command
(perhaps because it only expects ABOR in this state)

At the end of transmission it sends the transmission status (usually 226)


3) BulletProof FTP Server:

During a transmission Pure-FTPd replies to NOOPs immediately with:
200 NOOP command successful.

If there was at least one NOOP and the command is STOR, the transmission status 
is not sent.
If there were no NOOPs or the command is RETR, then the status is returned 
(usually 226)

4) Most other FTP servers:
NOOP replies are delayed. After a transmission completes, servers send 226 
first and the NOOP replies after that.



Here are possible response sequences:

- Pure-FTPd success
500,500,500,500,226
500,500,500,226,200 (in case of race condition)

- Pure-FTPd error (RETR data socket closed by client)
500,500,500,500,150
500,500,500,150,200 (in case of race condition)



- BulletProof FTP Server STOR, success/error (STOR data socket closed by client)
200,200,200,200,---
200,200,200,---,200 (in case of race condition)
226 (when no NOOPs sent)

- BulletProof FTP Server RETR, success
226 (when no NOOPs sent)
200,200,200,200,---
200,200,200,---,200 (in case of race condition)

- BulletProof FTP Server RETR, error (RETR data socket closed by client)
426 (when no NOOPs sent)
200,200,200,200,426
200,200,200,426,200 (in case of race condition)



- Most other FTP servers success
226,200,200,200,200 (no race condition possible)

- Most other FTP servers error (RETR data socket closed by client)
426,200,200,200,200 (no race condition possible)



Conclusion:
If we consume NOOP responses during the transmission, most of the time 
completePendingCommand() consumes the right response:
If a server does not support asynchronous NOOPs, then completePendingCommand() 
consumes the status and cleanUp() consumes all NOOP responses.
If a server supports asynchronous NOOPs, then all NOOP replies are consumed 
before completePendingCommand() is called.
(Except for BulletProof STOR, that forgets to send 226, so 
completePendingCommand() fails with SocketTimeoutException)

In case of a race condition (for asyncronous servers):
If transmission succeeds, completePendingCommand() consumes either 226 or "200 
NOOP command successful." and return true in either case.
If transmission fails, Util.copyStream() may throw something. If it doesn't, 
completePendingCommand() consumes "200 NOOP command successful." and returns 
false positive.
This can happen if last data block was sent by client, but never received by 
server.

If we delay consuming NOOP responses from asynchronous servers, 
completePendingCommand() always consumes the first NOOP response.
In case of Pure-FTPd, it is "500 Unknown command", so the method returns false 
negative.
For other asynchronous servers it is "200 NOOP command successful." and a 
possible 426 status is eaten by cleanUp(), so the method returns false positive.

On the other hand, completePendingCommand() won't throw SocketTimeoutException 
for BulletProof STOR and besides, for servers that don't support async NOOPs we 
don't have to
wait in __noop()


I think that what we need to do is to collect (#NOOPs + 1) responses at the end 
with a read timeout 10s, filter out 500 and 200 and the remaining status will 
be 226 or an
error status.




On 19.10.2017 20:46, Basin Ilya wrote:
> Ok, so I found these two that support it:
> - BulletProof FTP Server
> - Pure-FTPd
> 
> Will test further.
> 
> On 17.10.2017 18:29, sebb wrote:
>> On 17 October 2017 at 16:01, Basin Ilya  wrote:
>>> Hi sebb
>>>
 No, because some FTP servers *do* support asynchronous control channels.
>>> Do you know any?
>>
>> I cannot remember the name, but I know I came across at least one when 
>> testing.
>>
>> But even if there were currently no such servers, AFAIK it is
>> permitted by the RFCs so NET should not assume there are none.
>>
>>>
>>> On 17.10.2017 17:54, sebb wrote:
 On 17 October 2017 at 12:34, Basin Ilya  wrote:
> Hi.
> I'm using
> FTPClient.retrieveFileStream()
>
> and therefore I need to implement keepalive mechanism by my own.

Re: [VOTE] Release Apache Commons Codec 1.11 from RC1

2017-10-20 Thread Pascal Schumacher 

+1

Am 17.10.2017 um 20:30 schrieb Gary Gregory:

Hi All,

We have fixed quite a few bugs and added some significant enhancements
since Apache Commons Codec 1.10 was released, so I would like to release
Apache Commons Codec 1.11.

Apache Commons Codec 1.11 RC1 is available for review here:
 https://dist.apache.org/repos/dist/dev/commons/codec at revision 22530
 Get it like this: svn co
https://dist.apache.org/repos/dist/dev/commons/codec

The tag is here:

https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.11-RC1
svn revision 1812411.
 The SVN revision is noted because SVN tags are not immutable.
 Get it like this: svn co
https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec-1.11-RC1

Maven artifacts are here:

https://repository.apache.org/service/local/repositories/orgapachecommons-1280

These are the artifacts and their SHA1 hashes:

/commons-codec/commons-codec/1.11/commons-codec-1.11-javadoc.jar
(SHA1: 978245f8bd06d70703fa3180554c62891500f97a)
/commons-codec/commons-codec/1.11/commons-codec-1.11-src.zip.asc
(SHA1: e7ae399382030672890331dbf2a5e5014e1febec)
/commons-codec/commons-codec/1.11/commons-codec-1.11-tests.jar.asc
(SHA1: 15c48130bfc257b9e668910a344168da97a535ed)
/commons-codec/commons-codec/1.11/commons-codec-1.11.pom.asc
(SHA1: 5c7c9df6b11c0a9efae0890ba9a3e4f6f85d74b0)
/commons-codec/commons-codec/1.11/commons-codec-1.11-sources.jar.asc
(SHA1: c80656e5dd8e46341db814bcef89c03f821db6f8)
/commons-codec/commons-codec/1.11/commons-codec-1.11-bin.tar.gz
(SHA1: 59cf4653ec88c4a9fb3b95ecd065ba5229788a5c)
/commons-codec/commons-codec/1.11/commons-codec-1.11-src.tar.gz
(SHA1: 6ba24a55e5f8a8d7c9fdf28e8cb4edcc0fe44626)
/commons-codec/commons-codec/1.11/commons-codec-1.11.pom
(SHA1: 093ee1760aba62d6896d578bd7d247d0fa52f0e7)
/commons-codec/commons-codec/1.11/commons-codec-1.11-sources.jar
(SHA1: bce4ba84fd527950e35040b20a991c63e90e2850)
/commons-codec/commons-codec/1.11/commons-codec-1.11-tests.jar
(SHA1: 8a0430c3138ce4a23b0b6c7b7409df54bb76feb9)
/commons-codec/commons-codec/1.11/commons-codec-1.11-bin.zip
(SHA1: 63e6cc02e648b7d46f50bf0c4d6ffcafeddf8d04)
/commons-codec/commons-codec/1.11/commons-codec-1.11.jar
(SHA1: 3acb4705652e16236558f0f4f2192cc33c3bd189)
/commons-codec/commons-codec/1.11/commons-codec-1.11-src.zip
(SHA1: b45a09ea3711a9346c71d062e5f06935685db9fb)
/commons-codec/commons-codec/1.11/commons-codec-1.11-javadoc.jar.asc
(SHA1: 5e7eb8e6e1e51017d6fc52eaec5ad67dcc2c9dce)
/commons-codec/commons-codec/1.11/commons-codec-1.11-test-sources.jar.asc
(SHA1: 5f8c723bbcf08c8c4434a6731fe52d5e5cd9df9b)
/commons-codec/commons-codec/1.11/commons-codec-1.11.jar.asc
(SHA1: 42f6f623c1448aea511f4ee77d62d4b962f68450)
/commons-codec/commons-codec/1.11/commons-codec-1.11-test-sources.jar
(SHA1: 67f923eb8f532cc8de6e30e7baad3de872ea49f8)
/commons-codec/commons-codec/1.11/commons-codec-1.11-bin.zip.asc
(SHA1: fae75e01aa6492e4659d2140fadff2878984b5c0)
/commons-codec/commons-codec/1.11/commons-codec-1.11-bin.tar.gz.asc
(SHA1: 3eac777bbd8527dd62ad53349a0eaa1d5a4cc830)
/commons-codec/commons-codec/1.11/commons-codec-1.11-src.tar.gz.asc
(SHA1: d96909338df98272e81d9c4ea2b49f849e095ee8)

I tested this RC using 'mvn clean verify' on Windows 10 (Version
10.0.15063) with Oracle Java 7, Oracle Java 8, Oracle Java 9 and IBM Java 8
using Maven 3.5.0:

Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T13:39:06-06:00)
Maven home: C:\Java\apache-maven-3.5.0\bin\..
Java version: 1.7.0_80, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_80\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
=> BUILD SUCCESS

Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T13:39:06-06:00)
Maven home: C:\Java\apache-maven-3.5.0\bin\..
Java version: 1.8.0_144, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_144\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
=> BUILD SUCCESS

Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T13:39:06-06:00)
Maven home: C:\Java\apache-maven-3.5.0\bin\..
Java version: 1.8.0, vendor: IBM Corporation
Java home: C:\eclipse\IBM-6.4.5\ibm_sdk80\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "x86", family: "windows"
java version "1.8.0"
Java(TM) SE Runtime Environment (build pwi3280sr4fp5-20170421_01(SR4 FP5))
IBM J9 VM (build 2.8, JRE 1.8.0 Windows 10 x86-32 20170419_344392 (JIT
enabled, AOT enabled)
J9VM - R28_20170419_1004_B344392
JIT  - tr.r14.java_20170419_344392
GC   - R28_20170419_1004_B344392
J9CL - 20170419_344392)
JCL - 20170420_01 based on Oracle jdk8u131-b11
=> BUILD SUCCESS

Testing with Oracle Java 9 and Maven 3.5.0 yields FAILURES. I propose to
address those in a follow up release.

Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;

[GitHub] commons-bcel pull request #18: Fix incorrect indentation

2017-10-20 Thread asfgit 
Github user asfgit closed the pull request at:

https://github.com/apache/commons-bcel/pull/18


---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org