You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2020/08/07 13:58:35 UTC
[IO] Test failures on Windows
As of recently, I am seing:
[INFO] Running org.apache.commons.io.FileUtilsTestCase
[ERROR] Tests run: 142, Failures: 2, Errors: 0, Skipped: 1, Time elapsed:
5.613 s <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase
[ERROR] testCopyFile2WithoutFileDatePreservation Time elapsed: 0.038 s
<<< FAILURE!
org.opentest4j.AssertionFailedError: Check last modified date not same as
input ==> expected: not equal but was: <1596807101505>
at
org.apache.commons.io.FileUtilsTestCase.testCopyFile2WithoutFileDatePreservation(FileUtilsTestCase.java:1229)
[ERROR] testCopyDirectoryPreserveDates Time elapsed: 0.027 s <<< FAILURE!
org.opentest4j.AssertionFailedError: expected: <true> but was: <false>
at
org.apache.commons.io.FileUtilsTestCase.testCopyDirectoryPreserveDates(FileUtilsTestCase.java:1403)
I am wondering if GitHub/Travis can also be set up to run at least one
build on Windows so we can catch issues like these?
Gary
Re: [IO] Test failures on Windows
Posted by sebb <se...@gmail.com>.
I've just checked the Jenkins build and IO on Windows looks fine:
https://ci-builds.apache.org/job/Commons/job/commons-net-windows/
On Fri, 7 Aug 2020 at 15:50, sebb <se...@gmail.com> wrote:
>
> On Fri, 7 Aug 2020 at 15:04, Matt Sicker <bo...@gmail.com> wrote:
> >
> > That sounds like a file modification time granularity issue. Does Windows
> > not support milliseconds or finer for file modification times?
>
> Could be; I thought I had allowed for that.
> I'll see if I can fix it for Windows.
>
> > It could be that the test executed too fast!
>
> No, I don't think that is the issue.
> The tests now use a backdated source file (10 minutes earlier) to
> reinstate the tests that had relied on Thread.sleep.
>
>
> > On Fri, Aug 7, 2020 at 09:01 Gary Gregory <ga...@gmail.com> wrote:
> >
> > > As of recently, I am seing:
> > >
> > > [INFO] Running org.apache.commons.io.FileUtilsTestCase
> > > [ERROR] Tests run: 142, Failures: 2, Errors: 0, Skipped: 1, Time elapsed:
> > > 5.613 s <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase
> > > [ERROR] testCopyFile2WithoutFileDatePreservation Time elapsed: 0.038 s
> > > <<< FAILURE!
> > > org.opentest4j.AssertionFailedError: Check last modified date not same as
> > > input ==> expected: not equal but was: <1596807101505>
> > > at
> > > org.apache.commons.io
> > > .FileUtilsTestCase.testCopyFile2WithoutFileDatePreservation(FileUtilsTestCase.java:1229)
> > >
> > > [ERROR] testCopyDirectoryPreserveDates Time elapsed: 0.027 s <<< FAILURE!
> > > org.opentest4j.AssertionFailedError: expected: <true> but was: <false>
> > > at
> > > org.apache.commons.io
> > > .FileUtilsTestCase.testCopyDirectoryPreserveDates(FileUtilsTestCase.java:1403)
> > >
> > > I am wondering if GitHub/Travis can also be set up to run at least one
> > > build on Windows so we can catch issues like these?
> > >
> > > Gary
> > >
> > --
> > Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Test failures on Windows
Posted by sebb <se...@gmail.com>.
On Fri, 7 Aug 2020 at 15:04, Matt Sicker <bo...@gmail.com> wrote:
>
> That sounds like a file modification time granularity issue. Does Windows
> not support milliseconds or finer for file modification times?
Could be; I thought I had allowed for that.
I'll see if I can fix it for Windows.
> It could be that the test executed too fast!
No, I don't think that is the issue.
The tests now use a backdated source file (10 minutes earlier) to
reinstate the tests that had relied on Thread.sleep.
> On Fri, Aug 7, 2020 at 09:01 Gary Gregory <ga...@gmail.com> wrote:
>
> > As of recently, I am seing:
> >
> > [INFO] Running org.apache.commons.io.FileUtilsTestCase
> > [ERROR] Tests run: 142, Failures: 2, Errors: 0, Skipped: 1, Time elapsed:
> > 5.613 s <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase
> > [ERROR] testCopyFile2WithoutFileDatePreservation Time elapsed: 0.038 s
> > <<< FAILURE!
> > org.opentest4j.AssertionFailedError: Check last modified date not same as
> > input ==> expected: not equal but was: <1596807101505>
> > at
> > org.apache.commons.io
> > .FileUtilsTestCase.testCopyFile2WithoutFileDatePreservation(FileUtilsTestCase.java:1229)
> >
> > [ERROR] testCopyDirectoryPreserveDates Time elapsed: 0.027 s <<< FAILURE!
> > org.opentest4j.AssertionFailedError: expected: <true> but was: <false>
> > at
> > org.apache.commons.io
> > .FileUtilsTestCase.testCopyDirectoryPreserveDates(FileUtilsTestCase.java:1403)
> >
> > I am wondering if GitHub/Travis can also be set up to run at least one
> > build on Windows so we can catch issues like these?
> >
> > Gary
> >
> --
> Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Test failures on Windows
Posted by Matt Sicker <bo...@gmail.com>.
That's what I meant; bug fixes will be included in normal releases.
It's actually fairly similar to how the Jenkins LTS process works in
that LTS releases are basically just points chosen in time to maintain
as branches for backporting security fixes (slight difference being
that in Jenkins, we "upmerge" security fixes instead of backporting
for maximum compatibility) while everything else continues to be
released early and often (though Jenkins does weekly releases instead
of every 26 weeks like Java, and our LTS releases are more in line
with Java's regular release schedule).
As to what to do about broken code from upstream? We can make a shim
utility class for detecting if the bug is present and selecting the
appropriate behavior at runtime, or perhaps the production code should
be updated to use the NIO2 APIs which work properly unlike the old
File API.
On Sat, 8 Aug 2020 at 10:50, Gary Gregory <ga...@gmail.com> wrote:
>
> FWIW, there recently was a bug found by Commons Lang in Java 15 and 16.
> Java 16 has now fixed the bug but it will not be fixed in Java 15, at
> least not before GA.
>
>
> Gary
>
> On Sat, Aug 8, 2020, 11:45 Matt Sicker <bo...@gmail.com> wrote:
>
> > Even if it’s fixed upstream, it’ll never get backported most likely. Even
> > compiler bugs aren’t backported (see for example a bug related to
> > reflection on intersection types that was fixed in Java 9; I can’t find an
> > exact reference, but multiple bugs related to this were all address in 9).
> >
> > On Fri, Aug 7, 2020 at 12:03 sebb <se...@gmail.com> wrote:
> >
> > > If so, then it is not sufficient to run tests on Windows, it looks
> > > like we need to run tests on Windows with the appropriate version of
> > > Java.
> > >
> > > Presumably that is why Jenkins did not show the error.
> > >
> > > However, fixing the test won't fix the code - there may be instances
> > > of lastModified elsewhere.
> > >
> > > The Java bug needs to be fixed.
> > >
> > >
> > > On Fri, 7 Aug 2020 at 17:12, Gary Gregory <ga...@gmail.com>
> > wrote:
> > > >
> > > > On Fri, Aug 7, 2020 at 10:04 AM Matt Sicker <bo...@gmail.com> wrote:
> > > >
> > > > > That sounds like a file modification time granularity issue. Does
> > > Windows
> > > > > not support milliseconds or finer for file modification times? It
> > > could be
> > > > > that the test executed too fast!
> > > > >
> > > >
> > > > This might be a classic bug I've run into at work:
> > > > https://bugs.openjdk.java.net/browse/JDK-8177809
> > > >
> > > > Basically, never use File.lastModified(), use
> > > Files.getLastModifiedTime().
> > > >
> > > > Gary
> > > >
> > > >
> > > > >
> > > > > On Fri, Aug 7, 2020 at 09:01 Gary Gregory <ga...@gmail.com>
> > > wrote:
> > > > >
> > > > > > As of recently, I am seing:
> > > > > >
> > > > > > [INFO] Running org.apache.commons.io.FileUtilsTestCase
> > > > > > [ERROR] Tests run: 142, Failures: 2, Errors: 0, Skipped: 1, Time
> > > elapsed:
> > > > > > 5.613 s <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase
> > > > > > [ERROR] testCopyFile2WithoutFileDatePreservation Time elapsed:
> > > 0.038 s
> > > > > > <<< FAILURE!
> > > > > > org.opentest4j.AssertionFailedError: Check last modified date not
> > > same as
> > > > > > input ==> expected: not equal but was: <1596807101505>
> > > > > > at
> > > > > > org.apache.commons.io
> > > > > >
> > > > >
> > >
> > .FileUtilsTestCase.testCopyFile2WithoutFileDatePreservation(FileUtilsTestCase.java:1229)
> > > > > >
> > > > > > [ERROR] testCopyDirectoryPreserveDates Time elapsed: 0.027 s <<<
> > > > > FAILURE!
> > > > > > org.opentest4j.AssertionFailedError: expected: <true> but was:
> > > <false>
> > > > > > at
> > > > > > org.apache.commons.io
> > > > > >
> > > > >
> > >
> > .FileUtilsTestCase.testCopyDirectoryPreserveDates(FileUtilsTestCase.java:1403)
> > > > > >
> > > > > > I am wondering if GitHub/Travis can also be set up to run at least
> > > one
> > > > > > build on Windows so we can catch issues like these?
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > --
> > > > > Matt Sicker <bo...@gmail.com>
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > > --
> > Matt Sicker <bo...@gmail.com>
> >
--
Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Test failures on Windows
Posted by sebb <se...@gmail.com>.
The question is, what do we do about File.lastModified() calls in
Commons non-test code?
On Sat, 8 Aug 2020 at 16:50, Gary Gregory <ga...@gmail.com> wrote:
>
> FWIW, there recently was a bug found by Commons Lang in Java 15 and 16.
> Java 16 has now fixed the bug but it will not be fixed in Java 15, at
> least not before GA.
>
>
> Gary
>
> On Sat, Aug 8, 2020, 11:45 Matt Sicker <bo...@gmail.com> wrote:
>
> > Even if it’s fixed upstream, it’ll never get backported most likely. Even
> > compiler bugs aren’t backported (see for example a bug related to
> > reflection on intersection types that was fixed in Java 9; I can’t find an
> > exact reference, but multiple bugs related to this were all address in 9).
> >
> > On Fri, Aug 7, 2020 at 12:03 sebb <se...@gmail.com> wrote:
> >
> > > If so, then it is not sufficient to run tests on Windows, it looks
> > > like we need to run tests on Windows with the appropriate version of
> > > Java.
> > >
> > > Presumably that is why Jenkins did not show the error.
> > >
> > > However, fixing the test won't fix the code - there may be instances
> > > of lastModified elsewhere.
> > >
> > > The Java bug needs to be fixed.
> > >
> > >
> > > On Fri, 7 Aug 2020 at 17:12, Gary Gregory <ga...@gmail.com>
> > wrote:
> > > >
> > > > On Fri, Aug 7, 2020 at 10:04 AM Matt Sicker <bo...@gmail.com> wrote:
> > > >
> > > > > That sounds like a file modification time granularity issue. Does
> > > Windows
> > > > > not support milliseconds or finer for file modification times? It
> > > could be
> > > > > that the test executed too fast!
> > > > >
> > > >
> > > > This might be a classic bug I've run into at work:
> > > > https://bugs.openjdk.java.net/browse/JDK-8177809
> > > >
> > > > Basically, never use File.lastModified(), use
> > > Files.getLastModifiedTime().
> > > >
> > > > Gary
> > > >
> > > >
> > > > >
> > > > > On Fri, Aug 7, 2020 at 09:01 Gary Gregory <ga...@gmail.com>
> > > wrote:
> > > > >
> > > > > > As of recently, I am seing:
> > > > > >
> > > > > > [INFO] Running org.apache.commons.io.FileUtilsTestCase
> > > > > > [ERROR] Tests run: 142, Failures: 2, Errors: 0, Skipped: 1, Time
> > > elapsed:
> > > > > > 5.613 s <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase
> > > > > > [ERROR] testCopyFile2WithoutFileDatePreservation Time elapsed:
> > > 0.038 s
> > > > > > <<< FAILURE!
> > > > > > org.opentest4j.AssertionFailedError: Check last modified date not
> > > same as
> > > > > > input ==> expected: not equal but was: <1596807101505>
> > > > > > at
> > > > > > org.apache.commons.io
> > > > > >
> > > > >
> > >
> > .FileUtilsTestCase.testCopyFile2WithoutFileDatePreservation(FileUtilsTestCase.java:1229)
> > > > > >
> > > > > > [ERROR] testCopyDirectoryPreserveDates Time elapsed: 0.027 s <<<
> > > > > FAILURE!
> > > > > > org.opentest4j.AssertionFailedError: expected: <true> but was:
> > > <false>
> > > > > > at
> > > > > > org.apache.commons.io
> > > > > >
> > > > >
> > >
> > .FileUtilsTestCase.testCopyDirectoryPreserveDates(FileUtilsTestCase.java:1403)
> > > > > >
> > > > > > I am wondering if GitHub/Travis can also be set up to run at least
> > > one
> > > > > > build on Windows so we can catch issues like these?
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > --
> > > > > Matt Sicker <bo...@gmail.com>
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > > --
> > Matt Sicker <bo...@gmail.com>
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Test failures on Windows
Posted by Gary Gregory <ga...@gmail.com>.
FWIW, there recently was a bug found by Commons Lang in Java 15 and 16.
Java 16 has now fixed the bug but it will not be fixed in Java 15, at
least not before GA.
Gary
On Sat, Aug 8, 2020, 11:45 Matt Sicker <bo...@gmail.com> wrote:
> Even if it’s fixed upstream, it’ll never get backported most likely. Even
> compiler bugs aren’t backported (see for example a bug related to
> reflection on intersection types that was fixed in Java 9; I can’t find an
> exact reference, but multiple bugs related to this were all address in 9).
>
> On Fri, Aug 7, 2020 at 12:03 sebb <se...@gmail.com> wrote:
>
> > If so, then it is not sufficient to run tests on Windows, it looks
> > like we need to run tests on Windows with the appropriate version of
> > Java.
> >
> > Presumably that is why Jenkins did not show the error.
> >
> > However, fixing the test won't fix the code - there may be instances
> > of lastModified elsewhere.
> >
> > The Java bug needs to be fixed.
> >
> >
> > On Fri, 7 Aug 2020 at 17:12, Gary Gregory <ga...@gmail.com>
> wrote:
> > >
> > > On Fri, Aug 7, 2020 at 10:04 AM Matt Sicker <bo...@gmail.com> wrote:
> > >
> > > > That sounds like a file modification time granularity issue. Does
> > Windows
> > > > not support milliseconds or finer for file modification times? It
> > could be
> > > > that the test executed too fast!
> > > >
> > >
> > > This might be a classic bug I've run into at work:
> > > https://bugs.openjdk.java.net/browse/JDK-8177809
> > >
> > > Basically, never use File.lastModified(), use
> > Files.getLastModifiedTime().
> > >
> > > Gary
> > >
> > >
> > > >
> > > > On Fri, Aug 7, 2020 at 09:01 Gary Gregory <ga...@gmail.com>
> > wrote:
> > > >
> > > > > As of recently, I am seing:
> > > > >
> > > > > [INFO] Running org.apache.commons.io.FileUtilsTestCase
> > > > > [ERROR] Tests run: 142, Failures: 2, Errors: 0, Skipped: 1, Time
> > elapsed:
> > > > > 5.613 s <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase
> > > > > [ERROR] testCopyFile2WithoutFileDatePreservation Time elapsed:
> > 0.038 s
> > > > > <<< FAILURE!
> > > > > org.opentest4j.AssertionFailedError: Check last modified date not
> > same as
> > > > > input ==> expected: not equal but was: <1596807101505>
> > > > > at
> > > > > org.apache.commons.io
> > > > >
> > > >
> >
> .FileUtilsTestCase.testCopyFile2WithoutFileDatePreservation(FileUtilsTestCase.java:1229)
> > > > >
> > > > > [ERROR] testCopyDirectoryPreserveDates Time elapsed: 0.027 s <<<
> > > > FAILURE!
> > > > > org.opentest4j.AssertionFailedError: expected: <true> but was:
> > <false>
> > > > > at
> > > > > org.apache.commons.io
> > > > >
> > > >
> >
> .FileUtilsTestCase.testCopyDirectoryPreserveDates(FileUtilsTestCase.java:1403)
> > > > >
> > > > > I am wondering if GitHub/Travis can also be set up to run at least
> > one
> > > > > build on Windows so we can catch issues like these?
> > > > >
> > > > > Gary
> > > > >
> > > > --
> > > > Matt Sicker <bo...@gmail.com>
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> > --
> Matt Sicker <bo...@gmail.com>
>
Re: [IO] Test failures on Windows
Posted by Matt Sicker <bo...@gmail.com>.
Even if it’s fixed upstream, it’ll never get backported most likely. Even
compiler bugs aren’t backported (see for example a bug related to
reflection on intersection types that was fixed in Java 9; I can’t find an
exact reference, but multiple bugs related to this were all address in 9).
On Fri, Aug 7, 2020 at 12:03 sebb <se...@gmail.com> wrote:
> If so, then it is not sufficient to run tests on Windows, it looks
> like we need to run tests on Windows with the appropriate version of
> Java.
>
> Presumably that is why Jenkins did not show the error.
>
> However, fixing the test won't fix the code - there may be instances
> of lastModified elsewhere.
>
> The Java bug needs to be fixed.
>
>
> On Fri, 7 Aug 2020 at 17:12, Gary Gregory <ga...@gmail.com> wrote:
> >
> > On Fri, Aug 7, 2020 at 10:04 AM Matt Sicker <bo...@gmail.com> wrote:
> >
> > > That sounds like a file modification time granularity issue. Does
> Windows
> > > not support milliseconds or finer for file modification times? It
> could be
> > > that the test executed too fast!
> > >
> >
> > This might be a classic bug I've run into at work:
> > https://bugs.openjdk.java.net/browse/JDK-8177809
> >
> > Basically, never use File.lastModified(), use
> Files.getLastModifiedTime().
> >
> > Gary
> >
> >
> > >
> > > On Fri, Aug 7, 2020 at 09:01 Gary Gregory <ga...@gmail.com>
> wrote:
> > >
> > > > As of recently, I am seing:
> > > >
> > > > [INFO] Running org.apache.commons.io.FileUtilsTestCase
> > > > [ERROR] Tests run: 142, Failures: 2, Errors: 0, Skipped: 1, Time
> elapsed:
> > > > 5.613 s <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase
> > > > [ERROR] testCopyFile2WithoutFileDatePreservation Time elapsed:
> 0.038 s
> > > > <<< FAILURE!
> > > > org.opentest4j.AssertionFailedError: Check last modified date not
> same as
> > > > input ==> expected: not equal but was: <1596807101505>
> > > > at
> > > > org.apache.commons.io
> > > >
> > >
> .FileUtilsTestCase.testCopyFile2WithoutFileDatePreservation(FileUtilsTestCase.java:1229)
> > > >
> > > > [ERROR] testCopyDirectoryPreserveDates Time elapsed: 0.027 s <<<
> > > FAILURE!
> > > > org.opentest4j.AssertionFailedError: expected: <true> but was:
> <false>
> > > > at
> > > > org.apache.commons.io
> > > >
> > >
> .FileUtilsTestCase.testCopyDirectoryPreserveDates(FileUtilsTestCase.java:1403)
> > > >
> > > > I am wondering if GitHub/Travis can also be set up to run at least
> one
> > > > build on Windows so we can catch issues like these?
> > > >
> > > > Gary
> > > >
> > > --
> > > Matt Sicker <bo...@gmail.com>
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> --
Matt Sicker <bo...@gmail.com>
Re: [IO] Test failures on Windows
Posted by sebb <se...@gmail.com>.
If so, then it is not sufficient to run tests on Windows, it looks
like we need to run tests on Windows with the appropriate version of
Java.
Presumably that is why Jenkins did not show the error.
However, fixing the test won't fix the code - there may be instances
of lastModified elsewhere.
The Java bug needs to be fixed.
On Fri, 7 Aug 2020 at 17:12, Gary Gregory <ga...@gmail.com> wrote:
>
> On Fri, Aug 7, 2020 at 10:04 AM Matt Sicker <bo...@gmail.com> wrote:
>
> > That sounds like a file modification time granularity issue. Does Windows
> > not support milliseconds or finer for file modification times? It could be
> > that the test executed too fast!
> >
>
> This might be a classic bug I've run into at work:
> https://bugs.openjdk.java.net/browse/JDK-8177809
>
> Basically, never use File.lastModified(), use Files.getLastModifiedTime().
>
> Gary
>
>
> >
> > On Fri, Aug 7, 2020 at 09:01 Gary Gregory <ga...@gmail.com> wrote:
> >
> > > As of recently, I am seing:
> > >
> > > [INFO] Running org.apache.commons.io.FileUtilsTestCase
> > > [ERROR] Tests run: 142, Failures: 2, Errors: 0, Skipped: 1, Time elapsed:
> > > 5.613 s <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase
> > > [ERROR] testCopyFile2WithoutFileDatePreservation Time elapsed: 0.038 s
> > > <<< FAILURE!
> > > org.opentest4j.AssertionFailedError: Check last modified date not same as
> > > input ==> expected: not equal but was: <1596807101505>
> > > at
> > > org.apache.commons.io
> > >
> > .FileUtilsTestCase.testCopyFile2WithoutFileDatePreservation(FileUtilsTestCase.java:1229)
> > >
> > > [ERROR] testCopyDirectoryPreserveDates Time elapsed: 0.027 s <<<
> > FAILURE!
> > > org.opentest4j.AssertionFailedError: expected: <true> but was: <false>
> > > at
> > > org.apache.commons.io
> > >
> > .FileUtilsTestCase.testCopyDirectoryPreserveDates(FileUtilsTestCase.java:1403)
> > >
> > > I am wondering if GitHub/Travis can also be set up to run at least one
> > > build on Windows so we can catch issues like these?
> > >
> > > Gary
> > >
> > --
> > Matt Sicker <bo...@gmail.com>
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Test failures on Windows
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Aug 7, 2020 at 10:04 AM Matt Sicker <bo...@gmail.com> wrote:
> That sounds like a file modification time granularity issue. Does Windows
> not support milliseconds or finer for file modification times? It could be
> that the test executed too fast!
>
This might be a classic bug I've run into at work:
https://bugs.openjdk.java.net/browse/JDK-8177809
Basically, never use File.lastModified(), use Files.getLastModifiedTime().
Gary
>
> On Fri, Aug 7, 2020 at 09:01 Gary Gregory <ga...@gmail.com> wrote:
>
> > As of recently, I am seing:
> >
> > [INFO] Running org.apache.commons.io.FileUtilsTestCase
> > [ERROR] Tests run: 142, Failures: 2, Errors: 0, Skipped: 1, Time elapsed:
> > 5.613 s <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase
> > [ERROR] testCopyFile2WithoutFileDatePreservation Time elapsed: 0.038 s
> > <<< FAILURE!
> > org.opentest4j.AssertionFailedError: Check last modified date not same as
> > input ==> expected: not equal but was: <1596807101505>
> > at
> > org.apache.commons.io
> >
> .FileUtilsTestCase.testCopyFile2WithoutFileDatePreservation(FileUtilsTestCase.java:1229)
> >
> > [ERROR] testCopyDirectoryPreserveDates Time elapsed: 0.027 s <<<
> FAILURE!
> > org.opentest4j.AssertionFailedError: expected: <true> but was: <false>
> > at
> > org.apache.commons.io
> >
> .FileUtilsTestCase.testCopyDirectoryPreserveDates(FileUtilsTestCase.java:1403)
> >
> > I am wondering if GitHub/Travis can also be set up to run at least one
> > build on Windows so we can catch issues like these?
> >
> > Gary
> >
> --
> Matt Sicker <bo...@gmail.com>
>
Re: [IO] Test failures on Windows
Posted by Matt Sicker <bo...@gmail.com>.
That sounds like a file modification time granularity issue. Does Windows
not support milliseconds or finer for file modification times? It could be
that the test executed too fast!
On Fri, Aug 7, 2020 at 09:01 Gary Gregory <ga...@gmail.com> wrote:
> As of recently, I am seing:
>
> [INFO] Running org.apache.commons.io.FileUtilsTestCase
> [ERROR] Tests run: 142, Failures: 2, Errors: 0, Skipped: 1, Time elapsed:
> 5.613 s <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase
> [ERROR] testCopyFile2WithoutFileDatePreservation Time elapsed: 0.038 s
> <<< FAILURE!
> org.opentest4j.AssertionFailedError: Check last modified date not same as
> input ==> expected: not equal but was: <1596807101505>
> at
> org.apache.commons.io
> .FileUtilsTestCase.testCopyFile2WithoutFileDatePreservation(FileUtilsTestCase.java:1229)
>
> [ERROR] testCopyDirectoryPreserveDates Time elapsed: 0.027 s <<< FAILURE!
> org.opentest4j.AssertionFailedError: expected: <true> but was: <false>
> at
> org.apache.commons.io
> .FileUtilsTestCase.testCopyDirectoryPreserveDates(FileUtilsTestCase.java:1403)
>
> I am wondering if GitHub/Travis can also be set up to run at least one
> build on Windows so we can catch issues like these?
>
> Gary
>
--
Matt Sicker <bo...@gmail.com>
Re: [IO] Test failures on Windows
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Aug 7, 2020 at 10:09 AM Matt Sicker <bo...@gmail.com> wrote:
> You can basically copy the GitHub Actions setup we have in log4j2 minus the
> toolchains stuff (unless you need that too). GHA looks to support macOS
> runners as well.
>
It looks like we do it the same way...
https://github.community/t/error-when-evaluating-runs-on-for-job-build-line-x-col-y-unexpected-value/126455
Gary
>
> On Fri, Aug 7, 2020 at 09:07 Xeno Amess <xe...@gmail.com> wrote:
>
> > there be document on travis-ci about windows environment but I havn't
> seen
> > any java repo using it
> > https://docs.travis-ci.com/user/reference/windows/
> >
> > besides if my memory be correct, there be another site who have free
> > windows environment.
> > https://www.appveyor.com/
> >
> > Gary Gregory <ga...@gmail.com> 于2020年8月7日周五 下午10:01写道：
> >
> > > As of recently, I am seing:
> > >
> > > [INFO] Running org.apache.commons.io.FileUtilsTestCase
> > > [ERROR] Tests run: 142, Failures: 2, Errors: 0, Skipped: 1, Time
> elapsed:
> > > 5.613 s <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase
> > > [ERROR] testCopyFile2WithoutFileDatePreservation Time elapsed: 0.038 s
> > > <<< FAILURE!
> > > org.opentest4j.AssertionFailedError: Check last modified date not same
> as
> > > input ==> expected: not equal but was: <1596807101505>
> > > at
> > > org.apache.commons.io
> > >
> >
> .FileUtilsTestCase.testCopyFile2WithoutFileDatePreservation(FileUtilsTestCase.java:1229)
> > >
> > > [ERROR] testCopyDirectoryPreserveDates Time elapsed: 0.027 s <<<
> > FAILURE!
> > > org.opentest4j.AssertionFailedError: expected: <true> but was: <false>
> > > at
> > > org.apache.commons.io
> > >
> >
> .FileUtilsTestCase.testCopyDirectoryPreserveDates(FileUtilsTestCase.java:1403)
> > >
> > > I am wondering if GitHub/Travis can also be set up to run at least one
> > > build on Windows so we can catch issues like these?
> > >
> > > Gary
> > >
> >
> --
> Matt Sicker <bo...@gmail.com>
>
Re: [IO] Test failures on Windows
Posted by Matt Sicker <bo...@gmail.com>.
You can basically copy the GitHub Actions setup we have in log4j2 minus the
toolchains stuff (unless you need that too). GHA looks to support macOS
runners as well.
On Fri, Aug 7, 2020 at 09:07 Xeno Amess <xe...@gmail.com> wrote:
> there be document on travis-ci about windows environment but I havn't seen
> any java repo using it
> https://docs.travis-ci.com/user/reference/windows/
>
> besides if my memory be correct, there be another site who have free
> windows environment.
> https://www.appveyor.com/
>
> Gary Gregory <ga...@gmail.com> 于2020年8月7日周五 下午10:01写道：
>
> > As of recently, I am seing:
> >
> > [INFO] Running org.apache.commons.io.FileUtilsTestCase
> > [ERROR] Tests run: 142, Failures: 2, Errors: 0, Skipped: 1, Time elapsed:
> > 5.613 s <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase
> > [ERROR] testCopyFile2WithoutFileDatePreservation Time elapsed: 0.038 s
> > <<< FAILURE!
> > org.opentest4j.AssertionFailedError: Check last modified date not same as
> > input ==> expected: not equal but was: <1596807101505>
> > at
> > org.apache.commons.io
> >
> .FileUtilsTestCase.testCopyFile2WithoutFileDatePreservation(FileUtilsTestCase.java:1229)
> >
> > [ERROR] testCopyDirectoryPreserveDates Time elapsed: 0.027 s <<<
> FAILURE!
> > org.opentest4j.AssertionFailedError: expected: <true> but was: <false>
> > at
> > org.apache.commons.io
> >
> .FileUtilsTestCase.testCopyDirectoryPreserveDates(FileUtilsTestCase.java:1403)
> >
> > I am wondering if GitHub/Travis can also be set up to run at least one
> > build on Windows so we can catch issues like these?
> >
> > Gary
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: [IO] Test failures on Windows
Posted by Xeno Amess <xe...@gmail.com>.
there be document on travis-ci about windows environment but I havn't seen
any java repo using it
https://docs.travis-ci.com/user/reference/windows/
besides if my memory be correct, there be another site who have free
windows environment.
https://www.appveyor.com/
Gary Gregory <ga...@gmail.com> 于2020年8月7日周五 下午10:01写道：
> As of recently, I am seing:
>
> [INFO] Running org.apache.commons.io.FileUtilsTestCase
> [ERROR] Tests run: 142, Failures: 2, Errors: 0, Skipped: 1, Time elapsed:
> 5.613 s <<< FAILURE! - in org.apache.commons.io.FileUtilsTestCase
> [ERROR] testCopyFile2WithoutFileDatePreservation Time elapsed: 0.038 s
> <<< FAILURE!
> org.opentest4j.AssertionFailedError: Check last modified date not same as
> input ==> expected: not equal but was: <1596807101505>
> at
> org.apache.commons.io
> .FileUtilsTestCase.testCopyFile2WithoutFileDatePreservation(FileUtilsTestCase.java:1229)
>
> [ERROR] testCopyDirectoryPreserveDates Time elapsed: 0.027 s <<< FAILURE!
> org.opentest4j.AssertionFailedError: expected: <true> but was: <false>
> at
> org.apache.commons.io
> .FileUtilsTestCase.testCopyDirectoryPreserveDates(FileUtilsTestCase.java:1403)
>
> I am wondering if GitHub/Travis can also be set up to run at least one
> build on Windows so we can catch issues like these?
>
> Gary
>