Re: [IO] Releasing 2.6
On Sep 30, 2017 02:58, "Benedikt Ritter" wrote:
Okay, I'll cut RC1 this afternoon.
Benedikt
Great!
Gary
Pascal Schumacher 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
> > :
> >> 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: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: [IO] Releasing 2.6
Okay, I'll cut RC1 this afternoon.
Benedikt
Pascal Schumacher 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
> > :
> >> 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: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: [IO] Releasing 2.6
Am 30.09.2017 um 10:26 schrieb Benedikt Ritter:
Am 28.09.2017 um 09:39 schrieb 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
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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] Releasing 2.6
> Am 28.09.2017 um 09:39 schrieb 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
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: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] Releasing 2.6
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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] Releasing 2.6
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
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
>> >>
>>> 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: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
--
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] Releasing 2.6
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 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] Releasing 2.6
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 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: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [IO] Releasing 2.6
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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] Releasing 2.6
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 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 > wrote: > >> I fixed that failure with some Git magic. >> >> Gary >> >> On Wed, Sep 27, 2017 at 12:32 AM, Benedikt Ritter >> wrote: >> >>> >>> > Am 27.09.2017 um 00:16 schrieb Gary Gregory : >>> > >>> > 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 >>> 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: dev-unsubscr...@commons.apache.org >>> >> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >>> >> >>> >>> >>> ---
Re: [IO] Releasing 2.6
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 wrote: > I fixed that failure with some Git magic. > > Gary > > On Wed, Sep 27, 2017 at 12:32 AM, Benedikt Ritter > wrote: > >> >> > Am 27.09.2017 um 00:16 schrieb Gary Gregory : >> > >> > 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 >> 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: dev-unsubscr...@commons.apache.org >> >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >
Re: [IO] Releasing 2.6
I fixed that failure with some Git magic. Gary On Wed, Sep 27, 2017 at 12:32 AM, Benedikt Ritter wrote: > > > Am 27.09.2017 um 00:16 schrieb Gary Gregory : > > > > 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 > 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: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [IO] Releasing 2.6
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 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 >> 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: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] Releasing 2.6
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 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] Releasing 2.6
> Am 27.09.2017 um 00:16 schrieb Gary Gregory : > > 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 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: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] Releasing 2.6
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 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 > 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 > 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: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > -- Matt Sicker
Re: [IO] Releasing 2.6
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 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 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: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [IO] Releasing 2.6
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 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: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [IO] Releasing 2.6
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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] Releasing 2.6
Go for it! :-) Gary On Tue, Sep 26, 2017 at 2:48 PM, Benedikt Ritter 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: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
