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 "up
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 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 no
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 wrote:
> Even if it’s fixed upstream, it’ll never get backported most likely. Even
> c
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,
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
On Fri, Aug 7, 2020 at 10:04 AM Matt Sicker 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:
http
On Fri, Aug 7, 2020 at 10:09 AM Matt Sicker 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-
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 wrote:
>
> On Fri, 7 Aug 2020 at 15:04, Matt Sicker wrote:
> >
> > That sounds like a file modification time granularity issue. D
On Fri, 7 Aug 2020 at 15:04, Matt Sicker 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
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 wrote:
> there be document on travis-ci about windows environment but I havn't seen
> any j
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 于2020年8月7日周五 下午10:
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 wrote:
> As of recently, I am seing:
>
> [INFO] Running org.apache.commo
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
<<
13 matches
Mail list logo
