[IO] Releasing 2.6

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[IO] Releasing 2.6

Benedikt Ritter-4
Hey,

I’m going through the list of components I happen to work with and make them ready for Java 9. Since I’m blocked in the release process of collections because of the Windows test failures, I’m going to cut a RC for IO 2.6 probably tomorrow night.

Regards,
Benedikt
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] Releasing 2.6

garydgregory
Go for it! :-)

Gary

On Tue, Sep 26, 2017 at 2:48 PM, Benedikt Ritter <[hidden email]> wrote:

> Hey,
>
> I’m going through the list of components I happen to work with and make
> them ready for Java 9. Since I’m blocked in the release process of
> collections because of the Windows test failures, I’m going to cut a RC for
> IO 2.6 probably tomorrow night.
>
> Regards,
> Benedikt
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [IO] Releasing 2.6

Pascal Schumacher
In reply to this post by Benedikt Ritter-4
Great new! Thanks!

Am 26.09.2017 um 22:48 schrieb Benedikt Ritter:

> Hey,
>
> I’m going through the list of components I happen to work with and make them ready for Java 9. Since I’m blocked in the release process of collections because of the Windows test failures, I’m going to cut a RC for IO 2.6 probably tomorrow night.
>
> Regards,
> Benedikt
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] Releasing 2.6

garydgregory
In reply to this post by Benedikt Ritter-4
This test fails on Windows:

org.apache.commons.io.FileUtilsTestCase

FileUtilsTestCase
org.apache.commons.io.FileUtilsTestCase
testContentEqualsIgnoreEOL(org.apache.commons.io.FileUtilsTestCase)
java.lang.AssertionError

at org.junit.Assert.fail(Assert.java:86)

at org.junit.Assert.assertTrue(Assert.java:41)

at org.junit.Assert.assertFalse(Assert.java:64)

at org.junit.Assert.assertFalse(Assert.java:74)

at
org.apache.commons.io.FileUtilsTestCase.testContentEqualsIgnoreEOL(FileUtilsTestCase.java:681)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)

at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)

at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)

at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)

at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)

at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)

at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)

at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)

at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)

at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)

at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)

at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)

at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)

at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)

at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)

at org.junit.runners.ParentRunner.run(ParentRunner.java:363)

at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)

at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)

at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:539)

at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:761)

at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:461)

at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:207)


Gary

On Tue, Sep 26, 2017 at 2:48 PM, Benedikt Ritter <[hidden email]> wrote:

> Hey,
>
> I’m going through the list of components I happen to work with and make
> them ready for Java 9. Since I’m blocked in the release process of
> collections because of the Windows test failures, I’m going to cut a RC for
> IO 2.6 probably tomorrow night.
>
> Regards,
> Benedikt
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [IO] Releasing 2.6

Bruno P. Kinoshita-2
I wonder if we have some windows jenkins slaves. It would be nice to identify these regressions earlier.
Bruno

Sent from Yahoo Mail on Android
 
  On Wed, 27 Sep 2017 at 8:16, Gary Gregory<[hidden email]> wrote:   This test fails on Windows:

org.apache.commons.io.FileUtilsTestCase

FileUtilsTestCase
org.apache.commons.io.FileUtilsTestCase
testContentEqualsIgnoreEOL(org.apache.commons.io.FileUtilsTestCase)
java.lang.AssertionError

at org.junit.Assert.fail(Assert.java:86)

at org.junit.Assert.assertTrue(Assert.java:41)

at org.junit.Assert.assertFalse(Assert.java:64)

at org.junit.Assert.assertFalse(Assert.java:74)

at
org.apache.commons.io.FileUtilsTestCase.testContentEqualsIgnoreEOL(FileUtilsTestCase.java:681)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)

at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)

at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)

at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)

at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)

at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)

at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)

at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)

at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)

at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)

at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)

at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)

at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)

at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)

at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)

at org.junit.runners.ParentRunner.run(ParentRunner.java:363)

at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)

at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)

at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:539)

at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:761)

at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:461)

at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:207)


Gary

On Tue, Sep 26, 2017 at 2:48 PM, Benedikt Ritter <[hidden email]> wrote:

> Hey,
>
> I’m going through the list of components I happen to work with and make
> them ready for Java 9. Since I’m blocked in the release process of
> collections because of the Windows test failures, I’m going to cut a RC for
> IO 2.6 probably tomorrow night.
>
> Regards,
> Benedikt
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>  
Reply | Threaded
Open this post in threaded view
|

Re: [IO] Releasing 2.6

Matt Sicker
There used to be Windows Jenkins slaves. I had them configured for Log4j
here: https://builds.apache.org/job/Log4jWindows/

Not sure if they're working properly, but I see 3 nodes:
https://builds.apache.org/label/Windows/

On 26 September 2017 at 17:52, Bruno P. Kinoshita <[hidden email]> wrote:

> I wonder if we have some windows jenkins slaves. It would be nice to
> identify these regressions earlier.
> Bruno
>
> Sent from Yahoo Mail on Android
>
>   On Wed, 27 Sep 2017 at 8:16, Gary Gregory<[hidden email]>
> wrote:   This test fails on Windows:
>
> org.apache.commons.io.FileUtilsTestCase
>
> FileUtilsTestCase
> org.apache.commons.io.FileUtilsTestCase
> testContentEqualsIgnoreEOL(org.apache.commons.io.FileUtilsTestCase)
> java.lang.AssertionError
>
> at org.junit.Assert.fail(Assert.java:86)
>
> at org.junit.Assert.assertTrue(Assert.java:41)
>
> at org.junit.Assert.assertFalse(Assert.java:64)
>
> at org.junit.Assert.assertFalse(Assert.java:74)
>
> at
> org.apache.commons.io.FileUtilsTestCase.testContentEqualsIgnoreEOL(
> FileUtilsTestCase.java:681)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 57)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:606)
>
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
> FrameworkMethod.java:50)
>
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(
> ReflectiveCallable.java:12)
>
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(
> FrameworkMethod.java:47)
>
> at
> org.junit.internal.runners.statements.InvokeMethod.
> evaluate(InvokeMethod.java:17)
>
> at
> org.junit.internal.runners.statements.RunBefores.
> evaluate(RunBefores.java:26)
>
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(
> RunAfters.java:27)
>
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:78)
>
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:57)
>
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(
> JUnit4TestReference.java:86)
>
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.
> run(TestExecution.java:38)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
> runTests(RemoteTestRunner.java:539)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
> runTests(RemoteTestRunner.java:761)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
> run(RemoteTestRunner.java:461)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
> main(RemoteTestRunner.java:207)
>
>
> Gary
>
> On Tue, Sep 26, 2017 at 2:48 PM, Benedikt Ritter <[hidden email]>
> wrote:
>
> > Hey,
> >
> > I’m going through the list of components I happen to work with and make
> > them ready for Java 9. Since I’m blocked in the release process of
> > collections because of the Windows test failures, I’m going to cut a RC
> for
> > IO 2.6 probably tomorrow night.
> >
> > Regards,
> > Benedikt
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>



--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [IO] Releasing 2.6

Benedikt Ritter-4
In reply to this post by garydgregory

> Am 27.09.2017 um 00:16 schrieb Gary Gregory <[hidden email]>:
>
> This test fails on Windows:

Can’t we just drop Windows support? :(

Do you have some time to investigate this?

Cheers,
Benedikt

>
> org.apache.commons.io.FileUtilsTestCase
>
> FileUtilsTestCase
> org.apache.commons.io.FileUtilsTestCase
> testContentEqualsIgnoreEOL(org.apache.commons.io.FileUtilsTestCase)
> java.lang.AssertionError
>
> at org.junit.Assert.fail(Assert.java:86)
>
> at org.junit.Assert.assertTrue(Assert.java:41)
>
> at org.junit.Assert.assertFalse(Assert.java:64)
>
> at org.junit.Assert.assertFalse(Assert.java:74)
>
> at
> org.apache.commons.io.FileUtilsTestCase.testContentEqualsIgnoreEOL(FileUtilsTestCase.java:681)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:606)
>
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:539)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:761)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:461)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:207)
>
>
> Gary
>
> On Tue, Sep 26, 2017 at 2:48 PM, Benedikt Ritter <[hidden email]> wrote:
>
>> Hey,
>>
>> I’m going through the list of components I happen to work with and make
>> them ready for Java 9. Since I’m blocked in the release process of
>> collections because of the Windows test failures, I’m going to cut a RC for
>> IO 2.6 probably tomorrow night.
>>
>> Regards,
>> Benedikt
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] Releasing 2.6

Pascal Schumacher
In reply to this post by garydgregory
Strange.

I just ran the commons-io test three times on windows 10 and every run
was successful.

Are you sure that you are not seeing on of the occasional failures that
the io test suffer from?

Am 27.09.2017 um 00:16 schrieb Gary Gregory:

> This test fails on Windows:
>
> org.apache.commons.io.FileUtilsTestCase
>
> FileUtilsTestCase
> org.apache.commons.io.FileUtilsTestCase
> testContentEqualsIgnoreEOL(org.apache.commons.io.FileUtilsTestCase)
> java.lang.AssertionError
>
> at org.junit.Assert.fail(Assert.java:86)
>
> at org.junit.Assert.assertTrue(Assert.java:41)
>
> at org.junit.Assert.assertFalse(Assert.java:64)
>
> at org.junit.Assert.assertFalse(Assert.java:74)
>
> at
> org.apache.commons.io.FileUtilsTestCase.testContentEqualsIgnoreEOL(FileUtilsTestCase.java:681)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:606)
>
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:539)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:761)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:461)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:207)
>
>
> Gary
>
> On Tue, Sep 26, 2017 at 2:48 PM, Benedikt Ritter <[hidden email]> wrote:
>
>> Hey,
>>
>> I’m going through the list of components I happen to work with and make
>> them ready for Java 9. Since I’m blocked in the release process of
>> collections because of the Windows test failures, I’m going to cut a RC for
>> IO 2.6 probably tomorrow night.
>>
>> Regards,
>> Benedikt
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] Releasing 2.6

sebb-2-2
The current Jenkins build uses Windows:


https://builds.apache.org/view/A-D/view/Commons/job/commons-io/58/

Last few runs were successful.

On 27 September 2017 at 08:46, Pascal Schumacher
<[hidden email]> wrote:

> Strange.
>
> I just ran the commons-io test three times on windows 10 and every run was
> successful.
>
> Are you sure that you are not seeing on of the occasional failures that the
> io test suffer from?
>
>
> Am 27.09.2017 um 00:16 schrieb Gary Gregory:
>>
>> This test fails on Windows:
>>
>> org.apache.commons.io.FileUtilsTestCase
>>
>> FileUtilsTestCase
>> org.apache.commons.io.FileUtilsTestCase
>> testContentEqualsIgnoreEOL(org.apache.commons.io.FileUtilsTestCase)
>> java.lang.AssertionError
>>
>> at org.junit.Assert.fail(Assert.java:86)
>>
>> at org.junit.Assert.assertTrue(Assert.java:41)
>>
>> at org.junit.Assert.assertFalse(Assert.java:64)
>>
>> at org.junit.Assert.assertFalse(Assert.java:74)
>>
>> at
>>
>> org.apache.commons.io.FileUtilsTestCase.testContentEqualsIgnoreEOL(FileUtilsTestCase.java:681)
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>
>> at
>>
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>
>> at
>>
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>
>> at java.lang.reflect.Method.invoke(Method.java:606)
>>
>> at
>>
>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>>
>> at
>>
>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>>
>> at
>>
>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>>
>> at
>>
>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>>
>> at
>>
>> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>>
>> at
>>
>> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>>
>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>>
>> at
>>
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>>
>> at
>>
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>>
>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>>
>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>>
>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>>
>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>>
>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>>
>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>>
>> at
>>
>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>>
>> at
>>
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>>
>> at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:539)
>>
>> at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:761)
>>
>> at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:461)
>>
>> at
>>
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:207)
>>
>>
>> Gary
>>
>> On Tue, Sep 26, 2017 at 2:48 PM, Benedikt Ritter <[hidden email]>
>> wrote:
>>
>>> Hey,
>>>
>>> I’m going through the list of components I happen to work with and make
>>> them ready for Java 9. Since I’m blocked in the release process of
>>> collections because of the Windows test failures, I’m going to cut a RC
>>> for
>>> IO 2.6 probably tomorrow night.
>>>
>>> Regards,
>>> Benedikt
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] Releasing 2.6

garydgregory
In reply to this post by Benedikt Ritter-4
I fixed that failure with some Git magic.

Gary

On Wed, Sep 27, 2017 at 12:32 AM, Benedikt Ritter <[hidden email]>
wrote:

>
> > Am 27.09.2017 um 00:16 schrieb Gary Gregory <[hidden email]>:
> >
> > This test fails on Windows:
>
> Can’t we just drop Windows support? :(
>
> Do you have some time to investigate this?
>
> Cheers,
> Benedikt
>
> >
> > org.apache.commons.io.FileUtilsTestCase
> >
> > FileUtilsTestCase
> > org.apache.commons.io.FileUtilsTestCase
> > testContentEqualsIgnoreEOL(org.apache.commons.io.FileUtilsTestCase)
> > java.lang.AssertionError
> >
> > at org.junit.Assert.fail(Assert.java:86)
> >
> > at org.junit.Assert.assertTrue(Assert.java:41)
> >
> > at org.junit.Assert.assertFalse(Assert.java:64)
> >
> > at org.junit.Assert.assertFalse(Assert.java:74)
> >
> > at
> > org.apache.commons.io.FileUtilsTestCase.testContentEqualsIgnoreEOL(
> FileUtilsTestCase.java:681)
> >
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >
> > at
> > sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:57)
> >
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> >
> > at java.lang.reflect.Method.invoke(Method.java:606)
> >
> > at
> > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
> FrameworkMethod.java:50)
> >
> > at
> > org.junit.internal.runners.model.ReflectiveCallable.run(
> ReflectiveCallable.java:12)
> >
> > at
> > org.junit.runners.model.FrameworkMethod.invokeExplosively(
> FrameworkMethod.java:47)
> >
> > at
> > org.junit.internal.runners.statements.InvokeMethod.
> evaluate(InvokeMethod.java:17)
> >
> > at
> > org.junit.internal.runners.statements.RunBefores.
> evaluate(RunBefores.java:26)
> >
> > at
> > org.junit.internal.runners.statements.RunAfters.evaluate(
> RunAfters.java:27)
> >
> > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> >
> > at
> > org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:78)
> >
> > at
> > org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:57)
> >
> > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> >
> > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> >
> > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> >
> > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> >
> > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> >
> > at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> >
> > at
> > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(
> JUnit4TestReference.java:86)
> >
> > at
> > org.eclipse.jdt.internal.junit.runner.TestExecution.
> run(TestExecution.java:38)
> >
> > at
> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
> runTests(RemoteTestRunner.java:539)
> >
> > at
> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
> runTests(RemoteTestRunner.java:761)
> >
> > at
> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
> run(RemoteTestRunner.java:461)
> >
> > at
> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
> main(RemoteTestRunner.java:207)
> >
> >
> > Gary
> >
> > On Tue, Sep 26, 2017 at 2:48 PM, Benedikt Ritter <[hidden email]>
> wrote:
> >
> >> Hey,
> >>
> >> I’m going through the list of components I happen to work with and make
> >> them ready for Java 9. Since I’m blocked in the release process of
> >> collections because of the Windows test failures, I’m going to cut a RC
> for
> >> IO 2.6 probably tomorrow night.
> >>
> >> Regards,
> >> Benedikt
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [IO] Releasing 2.6

garydgregory
But I am also seeing random failures trying to set up and teardown the test
directory. For example:

java.lang.AssertionError: Could not create directory
C:\vcs\git\apache\commons\commons-io\target\test_io
        at
org.apache.commons.io.IOUtilsTestCase.setUp(IOUtilsTestCase.java:80)

testAsBufferedReader(org.apache.commons.io.IOUtilsTestCase)  Time elapsed:
0.016 sec  <<< FAILURE!
java.lang.AssertionError: Could not create directory
C:\vcs\git\apache\commons\commons-io\target\test_io
        at
org.apache.commons.io.IOUtilsTestCase.tearDown(IOUtilsTestCase.java:116)

I wonder if we need to force Maven to disable any concurrency when running
tests?

Gary


On Wed, Sep 27, 2017 at 11:49 AM, Gary Gregory <[hidden email]>
wrote:

> I fixed that failure with some Git magic.
>
> Gary
>
> On Wed, Sep 27, 2017 at 12:32 AM, Benedikt Ritter <[hidden email]>
> wrote:
>
>>
>> > Am 27.09.2017 um 00:16 schrieb Gary Gregory <[hidden email]>:
>> >
>> > This test fails on Windows:
>>
>> Can’t we just drop Windows support? :(
>>
>> Do you have some time to investigate this?
>>
>> Cheers,
>> Benedikt
>>
>> >
>> > org.apache.commons.io.FileUtilsTestCase
>> >
>> > FileUtilsTestCase
>> > org.apache.commons.io.FileUtilsTestCase
>> > testContentEqualsIgnoreEOL(org.apache.commons.io.FileUtilsTestCase)
>> > java.lang.AssertionError
>> >
>> > at org.junit.Assert.fail(Assert.java:86)
>> >
>> > at org.junit.Assert.assertTrue(Assert.java:41)
>> >
>> > at org.junit.Assert.assertFalse(Assert.java:64)
>> >
>> > at org.junit.Assert.assertFalse(Assert.java:74)
>> >
>> > at
>> > org.apache.commons.io.FileUtilsTestCase.testContentEqualsIgn
>> oreEOL(FileUtilsTestCase.java:681)
>> >
>> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> >
>> > at
>> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>> ssorImpl.java:57)
>> >
>> > at
>> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> thodAccessorImpl.java:43)
>> >
>> > at java.lang.reflect.Method.invoke(Method.java:606)
>> >
>> > at
>> > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
>> FrameworkMethod.java:50)
>> >
>> > at
>> > org.junit.internal.runners.model.ReflectiveCallable.run(Refl
>> ectiveCallable.java:12)
>> >
>> > at
>> > org.junit.runners.model.FrameworkMethod.invokeExplosively(Fr
>> ameworkMethod.java:47)
>> >
>> > at
>> > org.junit.internal.runners.statements.InvokeMethod.evaluate(
>> InvokeMethod.java:17)
>> >
>> > at
>> > org.junit.internal.runners.statements.RunBefores.evaluate(
>> RunBefores.java:26)
>> >
>> > at
>> > org.junit.internal.runners.statements.RunAfters.evaluate(Run
>> Afters.java:27)
>> >
>> > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>> >
>> > at
>> > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit
>> 4ClassRunner.java:78)
>> >
>> > at
>> > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit
>> 4ClassRunner.java:57)
>> >
>> > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>> >
>> > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>> >
>> > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>> >
>> > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>> >
>> > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>> >
>> > at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>> >
>> > at
>> > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.
>> run(JUnit4TestReference.java:86)
>> >
>> > at
>> > org.eclipse.jdt.internal.junit.runner.TestExecution.run(
>> TestExecution.java:38)
>> >
>> > at
>> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe
>> sts(RemoteTestRunner.java:539)
>> >
>> > at
>> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe
>> sts(RemoteTestRunner.java:761)
>> >
>> > at
>> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(
>> RemoteTestRunner.java:461)
>> >
>> > at
>> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(
>> RemoteTestRunner.java:207)
>> >
>> >
>> > Gary
>> >
>> > On Tue, Sep 26, 2017 at 2:48 PM, Benedikt Ritter <[hidden email]>
>> wrote:
>> >
>> >> Hey,
>> >>
>> >> I’m going through the list of components I happen to work with and make
>> >> them ready for Java 9. Since I’m blocked in the release process of
>> >> collections because of the Windows test failures, I’m going to cut a
>> RC for
>> >> IO 2.6 probably tomorrow night.
>> >>
>> >> Regards,
>> >> Benedikt
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [IO] Releasing 2.6

garydgregory
Actually, we should not manage our own test folder, we should let JUnit do
with the TemporaryFolder rule...

Gary

On Wed, Sep 27, 2017 at 11:58 AM, Gary Gregory <[hidden email]>
wrote:

> But I am also seeing random failures trying to set up and teardown the
> test directory. For example:
>
> java.lang.AssertionError: Could not create directory
> C:\vcs\git\apache\commons\commons-io\target\test_io
>         at org.apache.commons.io.IOUtilsTestCase.setUp(
> IOUtilsTestCase.java:80)
>
> testAsBufferedReader(org.apache.commons.io.IOUtilsTestCase)  Time
> elapsed: 0.016 sec  <<< FAILURE!
> java.lang.AssertionError: Could not create directory
> C:\vcs\git\apache\commons\commons-io\target\test_io
>         at org.apache.commons.io.IOUtilsTestCase.tearDown(
> IOUtilsTestCase.java:116)
>
> I wonder if we need to force Maven to disable any concurrency when running
> tests?
>
> Gary
>
>
> On Wed, Sep 27, 2017 at 11:49 AM, Gary Gregory <[hidden email]>
> wrote:
>
>> I fixed that failure with some Git magic.
>>
>> Gary
>>
>> On Wed, Sep 27, 2017 at 12:32 AM, Benedikt Ritter <[hidden email]>
>> wrote:
>>
>>>
>>> > Am 27.09.2017 um 00:16 schrieb Gary Gregory <[hidden email]>:
>>> >
>>> > This test fails on Windows:
>>>
>>> Can’t we just drop Windows support? :(
>>>
>>> Do you have some time to investigate this?
>>>
>>> Cheers,
>>> Benedikt
>>>
>>> >
>>> > org.apache.commons.io.FileUtilsTestCase
>>> >
>>> > FileUtilsTestCase
>>> > org.apache.commons.io.FileUtilsTestCase
>>> > testContentEqualsIgnoreEOL(org.apache.commons.io.FileUtilsTestCase)
>>> > java.lang.AssertionError
>>> >
>>> > at org.junit.Assert.fail(Assert.java:86)
>>> >
>>> > at org.junit.Assert.assertTrue(Assert.java:41)
>>> >
>>> > at org.junit.Assert.assertFalse(Assert.java:64)
>>> >
>>> > at org.junit.Assert.assertFalse(Assert.java:74)
>>> >
>>> > at
>>> > org.apache.commons.io.FileUtilsTestCase.testContentEqualsIgn
>>> oreEOL(FileUtilsTestCase.java:681)
>>> >
>>> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> >
>>> > at
>>> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>>> ssorImpl.java:57)
>>> >
>>> > at
>>> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>>> thodAccessorImpl.java:43)
>>> >
>>> > at java.lang.reflect.Method.invoke(Method.java:606)
>>> >
>>> > at
>>> > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
>>> FrameworkMethod.java:50)
>>> >
>>> > at
>>> > org.junit.internal.runners.model.ReflectiveCallable.run(Refl
>>> ectiveCallable.java:12)
>>> >
>>> > at
>>> > org.junit.runners.model.FrameworkMethod.invokeExplosively(Fr
>>> ameworkMethod.java:47)
>>> >
>>> > at
>>> > org.junit.internal.runners.statements.InvokeMethod.evaluate(
>>> InvokeMethod.java:17)
>>> >
>>> > at
>>> > org.junit.internal.runners.statements.RunBefores.evaluate(Ru
>>> nBefores.java:26)
>>> >
>>> > at
>>> > org.junit.internal.runners.statements.RunAfters.evaluate(Run
>>> Afters.java:27)
>>> >
>>> > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>>> >
>>> > at
>>> > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit
>>> 4ClassRunner.java:78)
>>> >
>>> > at
>>> > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit
>>> 4ClassRunner.java:57)
>>> >
>>> > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>>> >
>>> > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>>> >
>>> > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>>> >
>>> > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>>> >
>>> > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>>> >
>>> > at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>>> >
>>> > at
>>> > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.r
>>> un(JUnit4TestReference.java:86)
>>> >
>>> > at
>>> > org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test
>>> Execution.java:38)
>>> >
>>> > at
>>> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe
>>> sts(RemoteTestRunner.java:539)
>>> >
>>> > at
>>> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe
>>> sts(RemoteTestRunner.java:761)
>>> >
>>> > at
>>> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R
>>> emoteTestRunner.java:461)
>>> >
>>> > at
>>> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(
>>> RemoteTestRunner.java:207)
>>> >
>>> >
>>> > Gary
>>> >
>>> > On Tue, Sep 26, 2017 at 2:48 PM, Benedikt Ritter <[hidden email]>
>>> wrote:
>>> >
>>> >> Hey,
>>> >>
>>> >> I’m going through the list of components I happen to work with and
>>> make
>>> >> them ready for Java 9. Since I’m blocked in the release process of
>>> >> collections because of the Windows test failures, I’m going to cut a
>>> RC for
>>> >> IO 2.6 probably tomorrow night.
>>> >>
>>> >> Regards,
>>> >> Benedikt
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: [hidden email]
>>> >> For additional commands, e-mail: [hidden email]
>>> >>
>>> >>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [IO] Releasing 2.6

Pascal Schumacher
In reply to this post by garydgregory
Am 27.09.2017 um 19:58 schrieb Gary Gregory:
> I wonder if we need to force Maven to disable any concurrency when running
> tests?
That should not be necessary.

Maven/Maven-Surefire-Plugin does not run test in parallel by default.
The surefire configuration of commons-io does not specify the parallel
parameter and the forkcount parameter is set to 1 so the tests should be
executed sequentially.

Cheers,
Pascal

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] Releasing 2.6

garydgregory
I updated the tests to use JUnit's TemporaryFolder rule instead of the old
custom and _shared_ folder. No more random errors.

Gary

On Wed, Sep 27, 2017 at 1:05 PM, Pascal Schumacher <[hidden email]
> wrote:

> Am 27.09.2017 um 19:58 schrieb Gary Gregory:
>
>> I wonder if we need to force Maven to disable any concurrency when running
>> tests?
>>
> That should not be necessary.
>
> Maven/Maven-Surefire-Plugin does not run test in parallel by default. The
> surefire configuration of commons-io does not specify the parallel
> parameter and the forkcount parameter is set to 1 so the tests should be
> executed sequentially.
>
> Cheers,
> Pascal
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [IO] Releasing 2.6

Pascal Schumacher
Great!

That should reduce the number of random test failures.

I was just taking a look at this and the usage patterns of the folder
looked horrible. :/

Cheers,
Pascal

Am 27.09.2017 um 21:19 schrieb Gary Gregory:

> I updated the tests to use JUnit's TemporaryFolder rule instead of the old
> custom and _shared_ folder. No more random errors.
>
> Gary
>
> On Wed, Sep 27, 2017 at 1:05 PM, Pascal Schumacher <[hidden email]
>> wrote:
>> Am 27.09.2017 um 19:58 schrieb Gary Gregory:
>>
>>> I wonder if we need to force Maven to disable any concurrency when running
>>> tests?
>>>
>> That should not be necessary.
>>
>> Maven/Maven-Surefire-Plugin does not run test in parallel by default. The
>> surefire configuration of commons-io does not specify the parallel
>> parameter and the forkcount parameter is set to 1 so the tests should be
>> executed sequentially.
>>
>> Cheers,
>> Pascal
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] Releasing 2.6

Stian Soiland-Reyes
I only got one error on Windows 10 – thanks for the fixes, Pascal and Gary!


The new error is:
  FileSystemUtilsTestCase.testGetFreeSpace_String:89
expected:<1.02861164E8> but was:<1.0286066E8>


I have:
               5 Dir(s)  104,991,649,792 bytes free

Test calls:

            final long bytes = FileSystemUtils.freeSpace("");
            final long kb = FileSystemUtils.freeSpaceKb("");
            assertEquals((double) bytes / 1024, kb, 256d);


Presumably something else on my machine downloaded 504 kB between the
two freeSpace calls – which is not much these days – perhaps one email
:-)

I changed the test to use instead a 1% delta, which should generally
be a considerable amount of disk space (1 GB in my case), which is
still small enough to detect the ~2.4% difference between a kilobyte
vs kibibyte (the legacy freeSpaceKb is misnamed, it actually returns
kibibyte instead of pre-1998 “kilobyte”)

Also added javadoc that it's actually kibibytes -- perhaps a bit too
late :-) -- IO-506 deprecated the remaining methods of FileSystemUtils
in favour of java.nio.file.FileStore -- I think then we can deprecate
the whole FileSystemUtils  class as well.


On 27 September 2017 at 20:24, Pascal Schumacher
<[hidden email]> wrote:

> Great!
>
> That should reduce the number of random test failures.
>
> I was just taking a look at this and the usage patterns of the folder looked
> horrible. :/
>
> Cheers,
> Pascal
>
>
> Am 27.09.2017 um 21:19 schrieb Gary Gregory:
>>
>> I updated the tests to use JUnit's TemporaryFolder rule instead of the old
>> custom and _shared_ folder. No more random errors.
>>
>> Gary
>>
>> On Wed, Sep 27, 2017 at 1:05 PM, Pascal Schumacher
>> <[hidden email]
>>>
>>> wrote:
>>> Am 27.09.2017 um 19:58 schrieb Gary Gregory:
>>>
>>>> I wonder if we need to force Maven to disable any concurrency when
>>>> running
>>>> tests?
>>>>
>>> That should not be necessary.
>>>
>>> Maven/Maven-Surefire-Plugin does not run test in parallel by default. The
>>> surefire configuration of commons-io does not specify the parallel
>>> parameter and the forkcount parameter is set to 1 so the tests should be
>>> executed sequentially.
>>>
>>> Cheers,
>>> Pascal
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



--
Stian Soiland-Reyes
http://orcid.org/0000-0001-9842-9718

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] Releasing 2.6

Pascal Schumacher
Am 28.09.2017 um 00:14 schrieb Stian Soiland-Reyes:

> The new error is:
>    FileSystemUtilsTestCase.testGetFreeSpace_String:89
> expected:<1.02861164E8> but was:<1.0286066E8>
>
> I have:
>                 5 Dir(s)  104,991,649,792 bytes free
>
> Test calls:
>
>              final long bytes = FileSystemUtils.freeSpace("");
>              final long kb = FileSystemUtils.freeSpaceKb("");
>              assertEquals((double) bytes / 1024, kb, 256d);
>
> Presumably something else on my machine downloaded 504 kB between the
> two freeSpace calls – which is not much these days – perhaps one email
> :-)
>
> I changed the test to use instead a 1% delta, which should generally
> be a considerable amount of disk space (1 GB in my case), which is
> still small enough to detect the ~2.4% difference between a kilobyte
> vs kibibyte (the legacy freeSpaceKb is misnamed, it actually returns
> kibibyte instead of pre-1998 “kilobyte”)
Thanks!
> I think then we can deprecate the whole FileSystemUtils class as well.
+1

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] Releasing 2.6

Benedikt Ritter-4

> Am 28.09.2017 um 09:39 schrieb Pascal Schumacher <[hidden email]>:
>
> Am 28.09.2017 um 00:14 schrieb Stian Soiland-Reyes:
>> The new error is:
>>   FileSystemUtilsTestCase.testGetFreeSpace_String:89
>> expected:<1.02861164E8> but was:<1.0286066E8>
>>
>> I have:
>>                5 Dir(s)  104,991,649,792 bytes free
>>
>> Test calls:
>>
>>             final long bytes = FileSystemUtils.freeSpace("");
>>             final long kb = FileSystemUtils.freeSpaceKb("");
>>             assertEquals((double) bytes / 1024, kb, 256d);
>>
>> Presumably something else on my machine downloaded 504 kB between the
>> two freeSpace calls – which is not much these days – perhaps one email
>> :-)
>>
>> I changed the test to use instead a 1% delta, which should generally
>> be a considerable amount of disk space (1 GB in my case), which is
>> still small enough to detect the ~2.4% difference between a kilobyte
>> vs kibibyte (the legacy freeSpaceKb is misnamed, it actually returns
>> kibibyte instead of pre-1998 “kilobyte”)
> Thanks!
>> I think then we can deprecate the whole FileSystemUtils class as well.
> +1

Okay, so where are we standing? The random failures have been resolved by using JUnit temporary folder rule. I read that there is still one test failing on Windows.

Further more we want to deprecate FileSystemUtils class. I can do that later.

Benedikt

>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] Releasing 2.6

Pascal Schumacher
Am 30.09.2017 um 10:26 schrieb Benedikt Ritter:

> Am 28.09.2017 um 09:39 schrieb Pascal Schumacher
> <[hidden email]>:
>> Am 28.09.2017 um 00:14 schrieb Stian Soiland-Reyes:
>>> The new error is:
>>>    FileSystemUtilsTestCase.testGetFreeSpace_String:89
>>> expected:<1.02861164E8> but was:<1.0286066E8>
>>>
>>> I have:
>>>                 5 Dir(s)  104,991,649,792 bytes free
>>>
>>> Test calls:
>>>
>>>              final long bytes = FileSystemUtils.freeSpace("");
>>>              final long kb = FileSystemUtils.freeSpaceKb("");
>>>              assertEquals((double) bytes / 1024, kb, 256d);
>>>
>>> Presumably something else on my machine downloaded 504 kB between the
>>> two freeSpace calls – which is not much these days – perhaps one email
>>> :-)
>>>
>>> I changed the test to use instead a 1% delta, which should generally
>>> be a considerable amount of disk space (1 GB in my case), which is
>>> still small enough to detect the ~2.4% difference between a kilobyte
>>> vs kibibyte (the legacy freeSpaceKb is misnamed, it actually returns
>>> kibibyte instead of pre-1998 “kilobyte”)
>> Thanks!
>>> I think then we can deprecate the whole FileSystemUtils class as well.
>> +1
> I read that there is still one test failing on Windows.

No, Stain made the test more stable (less likely to fail).

I think we are ready for a release.

Cheer,
Pascal


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [IO] Releasing 2.6

Benedikt Ritter-4
Okay, I'll cut RC1 this afternoon.

Benedikt

Pascal Schumacher <[hidden email]> schrieb am Sa. 30. Sep. 2017
um 10:47:

> Am 30.09.2017 um 10:26 schrieb Benedikt Ritter:
> > Am 28.09.2017 um 09:39 schrieb Pascal Schumacher
> > <[hidden email]>:
> >> Am 28.09.2017 um 00:14 schrieb Stian Soiland-Reyes:
> >>> The new error is:
> >>>    FileSystemUtilsTestCase.testGetFreeSpace_String:89
> >>> expected:<1.02861164E8> but was:<1.0286066E8>
> >>>
> >>> I have:
> >>>                 5 Dir(s)  104,991,649,792 bytes free
> >>>
> >>> Test calls:
> >>>
> >>>              final long bytes = FileSystemUtils.freeSpace("");
> >>>              final long kb = FileSystemUtils.freeSpaceKb("");
> >>>              assertEquals((double) bytes / 1024, kb, 256d);
> >>>
> >>> Presumably something else on my machine downloaded 504 kB between the
> >>> two freeSpace calls – which is not much these days – perhaps one email
> >>> :-)
> >>>
> >>> I changed the test to use instead a 1% delta, which should generally
> >>> be a considerable amount of disk space (1 GB in my case), which is
> >>> still small enough to detect the ~2.4% difference between a kilobyte
> >>> vs kibibyte (the legacy freeSpaceKb is misnamed, it actually returns
> >>> kibibyte instead of pre-1998 “kilobyte”)
> >> Thanks!
> >>> I think then we can deprecate the whole FileSystemUtils class as well.
> >> +1
> > I read that there is still one test failing on Windows.
>
> No, Stain made the test more stable (less likely to fail).
>
> I think we are ready for a release.
>
> Cheer,
> Pascal
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
12