I added my thoughts to the test refactoring in
https://github.com/apache/commons-validator/pull/301 pull request.
Regards,
David
Gary Gregory ezt írta (időpont: 2024. dec. 26.,
Cs, 16:36):
> Thanks for the tip Sam!
>
> In git master, I just pushed using JUnit Pioneer instead of dire
Thanks for the tip Sam!
In git master, I just pushed using JUnit Pioneer instead of direct global
variables access for locales and timezones.
TY all for helping.
Gary
On Thu, Dec 26, 2024 at 9:16 AM tsz sum Ng wrote:
> Hi,
> Looks like the default timezone will affect the test.
&
Hi,
Looks like the default timezone will affect the test.
I can reproduce the error by adding
TimeZone.setDefault(TimeZone.getTimeZone("GMT-5"));
in the beginning of the test.
It is because the date is formatted according to the default timezone,
hence cal20051231
of 2005-12-31 01
ht=false,transitions=0,lastRule=null],firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=2005,MONTH=11,WEEK_OF_YEAR=52,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=365,DAY_OF_WEEK=7,DAY_OF_WEEK_IN_MONTH=5,AM_PM=0,HOUR=1,HOUR_OF_DAY=1,MINUTE=15,SECOND=0,MILLISECOND=0,ZONE_OFFSET=0,DST_OFFSET=0]
>
> Y
erates the
> Calendar wrongly for some reason on your system or the issue is in this
> specific test case only?
>
> Gary Gregory ezt írta (időpont: 2024. dec. 25.,
> Sze, 22:58):
>
> > Hi Dávid,
> >
> > Thank you for having a look.
> >
> > I can
e
Calendar wrongly for some reason on your system or the issue is in this
specific test case only?
Gary Gregory ezt írta (időpont: 2024. dec. 25.,
Sze, 22:58):
> Hi Dávid,
>
> Thank you for having a look.
>
> I can't figure out why this is failing on my setup. Quite annoying sin
oding: UTF-8
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>
> The test seems not changed functionally, just a bit of refactoring, so it
> should not be failing in my opinion.
> - There are a couple of variable ext
ws 10", version: "10.0", arch: "amd64", family: "windows"
The test seems not changed functionally, just a bit of refactoring, so it
should not be failing in my opinion.
- There are a couple of variable extraction
- Variable renaming from cal20050101 to cal20051
Hi All,
With the HEAD of git master (commit
2c1898f65ed46aa5c0f340f63b5e1f4a8b86e4f0), I get:
[WARNING] Tests run: 25, Failures: 0, Errors: 0, Skipped: 1, Time elapsed:
0.007 s -- in org.apache.commons.validator.routines.EmailValidatorTest
[INFO] Running org.apache.commons.validator.routines.Cale
> >
>
> > > [INFO] BUILD FAILURE
> > > [INFO]
> > >
>
> > > [INFO] Total time: 46.075 s
> > > [I
-
> > [INFO] BUILD FAILURE
> > [INFO]
> >
> > [INFO] Total time: 46.075 s
> > [INFO] Finished at: 2024-06-24T12:26:41Z
> > [INFO]
> > ---
-
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.2.5:test (default-test) on
> project commons-compress: There are test failures.
>
Source URL:
https://github.com/apache/commons-compress/archive/refs/tags/re
; > I was unsure how to identify the component in the subject header here, but
> > I'd noticed you've got the standard reference NIST data in your repo, here:
> >
> > https://github.com/apache/commons-math/tree/master/commons-math-legacy/src/test/resources/org/apache/
e, Mar 26, 2024 at 10:46 PM Orion Yeung wrote:
>
> Hello,
>
> I was unsure how to identify the component in the subject header here, but
> I'd noticed you've got the standard reference NIST data in your repo, here:
>
> https://github.com/apache/commons-math/tree/mas
s-math/tree/master/commons-math-legacy/src/test/resources/org/apache/commons/math4/legacy/stat/data
>
> that we - on a statistics Rust crate - realized we needed to stop
> redistributing in our repo. *I'm not a legal person, but I'm providing the
> heads up as it may be a copyright
Hello,
I was unsure how to identify the component in the subject header here, but
I'd noticed you've got the standard reference NIST data in your repo, here:
https://github.com/apache/commons-math/tree/master/commons-math-legacy/src/test/resources/org/apache/commons/math4/legacy/stat/
Le sam. 23 déc. 2023 à 23:50, sebb a écrit :
>
> On Sat, 23 Dec 2023 at 15:44, Gilles Sadowski wrote:
> >
> > Hello.
> >
> > Le sam. 23 déc. 2023 à 16:30, sebb a écrit :
> > >
> > > The test MultiStartMultivariateOptimizerTest.testCircleFitting [
On Sat, 23 Dec 2023 at 15:44, Gilles Sadowski wrote:
>
> Hello.
>
> Le sam. 23 déc. 2023 à 16:30, sebb a écrit :
> >
> > The test MultiStartMultivariateOptimizerTest.testCircleFitting [1]
> > seems to be flaky.
> >
> > It often fails with values below
Hello.
Le sam. 23 déc. 2023 à 16:30, sebb a écrit :
>
> The test MultiStartMultivariateOptimizerTest.testCircleFitting [1]
> seems to be flaky.
>
> It often fails with values below the expected minimum of 750.
>
> Does this indicate a real failure, or can the minimum be saf
The test MultiStartMultivariateOptimizerTest.testCircleFitting [1]
seems to be flaky.
It often fails with values below the expected minimum of 750.
Does this indicate a real failure, or can the minimum be safely reduced?
Sebb
[1]
https://github.com/apache/commons-math/blob
On Wed, 20 Dec 2023 at 16:16, Alex Herbert wrote:
>
> On Wed, 20 Dec 2023 at 13:19, sebb wrote:
> >
> > On Tue, 19 Dec 2023 at 16:08, Alex Herbert wrote:
> > >
> > > Thanks Sebb,
> > >
> > > Note that previously the GH action was running the default goal:
> > > 'clean verify javadoc:javadoc'.
>
On Wed, 20 Dec 2023 at 13:19, sebb wrote:
>
> On Tue, 19 Dec 2023 at 16:08, Alex Herbert wrote:
> >
> > Thanks Sebb,
> >
> > Note that previously the GH action was running the default goal:
> > 'clean verify javadoc:javadoc'.
> >
> > Since we now need to specify the 'deploy' goal as well the abov
On Tue, 19 Dec 2023 at 16:08, Alex Herbert wrote:
>
> Thanks Sebb,
>
> Note that previously the GH action was running the default goal:
> 'clean verify javadoc:javadoc'.
>
> Since we now need to specify the 'deploy' goal as well the above
> defaults can be switched in for your additions when Infra
Thanks Sebb,
Note that previously the GH action was running the default goal:
'clean verify javadoc:javadoc'.
Since we now need to specify the 'deploy' goal as well the above
defaults can be switched in for your additions when Infra have created
the credentials.
Alex
On Tue, 19 Dec 2023 at 14:2
Created https://issues.apache.org/jira/browse/INFRA-25297 to get
access to credentials
Added code to maven.yml to deploy the snapshot (needs to be enabled
when creds are granted)
-
To unsubscribe, e-mail: dev-unsubscr...@commons.
There are now separate cross-host image build and test jobs
docker_images.yml - creates the Docker images and stores them in the
ghcr.io package repo
maven_crosstest.yml - fetches the images and uses them to build/test
the code on different architectures
Some commits may cause both jobs to run
The current crypto release states the details of the tested
configurations on the home page:
https://commons.apache.org/proper/commons-crypto/
The current release is 1.2.0, which is not shown.
It ought really to be added.
What was the list for 1.2.0, and where can one find the test results
from
How to reproduce these test failures?
On Sat, Sep 9, 2023 at 12:33 PM sebb wrote:
> Some of the test runs fail when testing with the class:
>
> org.apache.commons.crypto.jna.OpenSslJna
>
> It looks like all the OSes complete the test OK if the default JNA
> library is used.
&g
1:51 PM Woonsan Ko wrote:
> Hi,
>
> While I was preparing a PR, I got test failures below after running
> `mvn` in the master branch of the commons-vfs.
> Any hints for this? (I'm with maven-3.9.2 on JDK 1.8 / windows 10.)
>
> Thanks!
>
> Woonsan
>
> -
>
Hi,
While I was preparing a PR, I got test failures below after running
`mvn` in the master branch of the commons-vfs.
Any hints for this? (I'm with maven-3.9.2 on JDK 1.8 / windows 10.)
Thanks!
Woonsan
-
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time
elapsed: 0.
Some of the test runs fail when testing with the class:
org.apache.commons.crypto.jna.OpenSslJna
It looks like all the OSes complete the test OK if the default JNA
library is used.
However for some reason its version does not always agree with the
default openSSL version.
This library can be
This is a test to trace the subscriber currently generating spam. Apologies to the other subscribers for the noise.
Hello.
Le lun. 3 avr. 2023 à 16:47, François Laferrière
a écrit :
>
> When running Junit tests on ACM 4.0-snapshot I get a lot of failures. Mostly
> (I supect) due to roundoff error beyond the tolerance of individual test. Is
> it just a problem on my computer (Ubuntu 22.04,
When running Junit tests on ACM 4.0-snapshot I get a lot of failures. Mostly (I
supect) due to roundoff error beyond the tolerance of individual test. Is it
just a problem on my computer (Ubuntu 22.04, Eclipse 4.23,
java-18-openJdk-amd64 with JavaSE-1.8 compliance) or a general problem (that
se tests to fail,
> which does not say much for our test coverage but these would be hard
> to find without specially crafted class files.
> - On Java8, the previously failing test
> VerifyJavaMathTestCase.testBigDecimal() passes but fails differently
> than it did when run on
cause tests to fail,
which does not say much for our test coverage but these would be hard
to find without specially crafted class files.
- On Java8, the previously failing test
VerifyJavaMathTestCase.testBigDecimal() passes but fails differently
than it did when run on Java 11 or above. I only enab
I will try to take a look at this later today.
Mark
-Original Message-
From: Gary D. Gregory [mailto:ggreg...@apache.org]
Sent: Thursday, November 17, 2022 7:14 AM
To: dev@commons.apache.org
Subject: Re: [BCEL] Invalid test or bug?
More specifically, javap says:
21
d VerifyJavaUtilTestCase
> >
> > Gary
> >
> > On 2022/11/17 13:00:21 "Gary D. Gregory" wrote:
> > > Hi All & Mark Roberts:
> > >
> > > I added JavaMathTestCase as a disabled test as it fails.
> > >
> > > Is this a le
; Gary
>
> On 2022/11/17 13:00:21 "Gary D. Gregory" wrote:
> > Hi All & Mark Roberts:
> >
> > I added JavaMathTestCase as a disabled test as it fails.
> >
> > Is this a legal test to try or do we have a bug?
> >
> > Gary
> >
>
Actually: VerifyJavaMathTestCase and VerifyJavaUtilTestCase
Gary
On 2022/11/17 13:00:21 "Gary D. Gregory" wrote:
> Hi All & Mark Roberts:
>
> I added JavaMathTestCase as a disabled test as it fails.
>
> Is this a legal test to try o
Hi All & Mark Roberts:
I added JavaMathTestCase as a disabled test as it fails.
Is this a legal test to try or do we have a bug?
Gary
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-
ocally and look at the JaCoCo report
in target/site/ in the report section of the site.
I think the component could benefit from more tests. If anyone has apps that
use BCEL that have bits that can be turned into tests, that would give us more
real-world test cases.
TY,
Gary
On 2022/10/27 11:
ting the incorrect test.
>
> The junit org.apache.commons.math4.neuralnet.NetworkTest#testIterationOrder
> in commons-math-neuralnet contradicts this behavior and checks if the neurons
> in the neuron map are ordered in increasing order. It would be best to remove
> this flaky tes
contradicts this behavior and checks if the neurons in
the neuron map are ordered in increasing order. It would be best to remove this
flaky test.
I have raised a PR for the same :
https://github.com/apache/commons-math/pull/213
[https://opengraph.githubassets.com
BCEL currently stands at 44% code coverage from tests, which needs
improvement obviously. Any help would be appreciated.
Gary
Thank you Matt!
On Thu, May 5, 2022, 23:52 Matt Juntunen wrote:
> Hello,
>
> I've created a PR with a fix for that test. However, I'm not familiar
> enough with the tar format to know if this is all that's needed or if
> there is a deeper issue that needs to be ad
Hello,
I've created a PR with a fix for that test. However, I'm not familiar
enough with the tar format to know if this is all that's needed or if
there is a deeper issue that needs to be addressed.
Regards,
Matt J
On Thu, May 5, 2022 at 8:41 PM Gary Gregory wrote:
>
> Hi
Hi All,
I discovered earlier today that most tests (expect pack200) tests were
being skipped when running the Maven test goal. This is likely due to
a combination of updating commons-parent from 52 to 53 and porting
from JUnit 4 to 5 which was not checked properly.
I fixed all that but there
I have created a revised design for the abstract test for the distributions.
The current design requires that a single parameterization of the
distribution is created and this is then tested for the PDF, CDF,
SurvivalFunction, and InverseCDF. There are also tests for consistency
of survival and
ain/
> > and I'd look into porting the tests from
> >
> https://svn.apache.org/repos/asf/harmony/enhanced/java/trunk/classlib/modules/pack200/src/test/
> > unless anybody else has also started to look into it.
>
> Back at 86% coverage.
>
> The tests are JUnit
look into porting the tests from
> >
> https://svn.apache.org/repos/asf/harmony/enhanced/java/trunk/classlib/modules/pack200/src/test/
> > unless anybody else has also started to look into it.
>
> Back at 86% coverage.
>
> The tests are JUnit 3.x style and I have left them at that.
/classlib/modules/pack200/src/test/
> unless anybody else has also started to look into it.
Back at 86% coverage.
The tests are JUnit 3.x style and I have left them at that. I basically
only changed the package names and removed a test that asserted a given
class was compiled f
Good idea, I mistakenly thought our coverage was better.
Gary
On Sat, Jul 3, 2021, 05:50 Stefan Bodewig wrote:
> Hi
>
> our current pack200 tests don't seem to cover much of the pack200 code
> imported from harmony and the overall test coverage of Compress as a
&g
Hi
our current pack200 tests don't seem to cover much of the pack200 code
imported from harmony and the overall test coverage of Compress as a
whole has dropped significantly (from 86% to 61%) as the new package
contains quite a bit of code.
I assume the code originates from
I don’t understand this. Log4j2 was one of the first adopters of multi-release
jars.
There were problems in the beginning but those have virtually all been
resolved.
We haven’t had any complaints in ages. Log4j 2 2.14.1 supports Java 8.
Fully supporting JPMS (i.e. - adding a module-info.java
Hello.
Le lun. 14 juin 2021 à 00:37, John Patrick a écrit :
>
> So I want to start using Java 11 and take advantage of Java Modules. But
> with a bug in Java Multi-Jar not supporting 1.8 as base and 11 upon that,
> and most dependencies I want to upgrade eventually get stuck on a commons
> projec
On Sun, 13 Jun 2021 at 23:37, John Patrick wrote:
>
> So I want to start using Java 11 and take advantage of Java Modules. But
> with a bug in Java Multi-Jar not supporting 1.8 as base and 11 upon that,
> and most dependencies I want to upgrade eventually get stuck on a commons
> project holding a
So I want to start using Java 11 and take advantage of Java Modules. But
with a bug in Java Multi-Jar not supporting 1.8 as base and 11 upon that,
and most dependencies I want to upgrade eventually get stuck on a commons
project holding a pure JPMS solution.
Potentially someone raise an enhancemen
Le jeu. 10 juin 2021 à 14:42, John Patrick a écrit :
>
> If the tests are valid and useful once post Java 1.8, what about
> starting the next release branch where the min version bumps to Java
> 11.
[Numbers] and related components were meant to replace and
improve some functionalities provided i
If the tests are valid and useful once post Java 1.8, what about
starting the next release branch where the min version bumps to Java
11.
As Java 17 starting ramp down starts today I believe so in 3 months we
will have 3 LTS (1.8, 11 and 17) releases. So technically Java 18
development starts tomor
Le jeu. 10 juin 2021 à 13:05, sebb a écrit :
>
> Thanks.
>
> I've updated the RELEASE-NOTES accordingly (feel free to tweak the text)
AFAIK, this is an auto-generated file (from changes.xml).
Gilles
>
> On Thu, 10 Jun 2021 at 00:58, Alex Herbert wrote:
> >
> > I have removed the requirement fo
Thanks.
I've updated the RELEASE-NOTES accordingly (feel free to tweak the text)
On Thu, 10 Jun 2021 at 00:58, Alex Herbert wrote:
>
> I have removed the requirement for Java 9 from the build. It is still used
> in the performance testing module.
>
> Alex
---
I have removed the requirement for Java 9 from the build. It is still used
in the performance testing module.
Alex
Note that the test could inspect the java version,
or use reflection to see if the method BigDecimal.sqrt() exists...
-r
Randy Strauss, cell: 650-861-1537
On 6/9/21, 2:57 PM, "sebb" wrote:
On Wed, 9 Jun 2021 at 19:58, Alex Herbert wrote:
>
> On Wed, 9 Jun 202
's main artifacts using JDK 8, but the build now
> > > requires JDK 9 for the tests and JMH performance tests.
> >
> > That seems wrong. If the code targets Java 8, it must be possible to
> > test it using Java 8.
> >
> > It's possibly OK to require JDK
's main artifacts using JDK 8, but the build now
> > > requires JDK 9 for the tests and JMH performance tests.
> >
> > That seems wrong. If the code targets Java 8, it must be possible to
> > test it using Java 8.
> >
> > It's possibly OK to require
x27;ve corrected that in the pom, thanks.
> >
> > I think the issue is that Gilles used JDK 8 to try and build it. You can
> > run using the project's main artifacts using JDK 8, but the build now
> > requires JDK 9 for the tests and JMH performance tests.
>
>
K 8 to try and build it. You can
> run using the project's main artifacts using JDK 8, but the build now
> requires JDK 9 for the tests and JMH performance tests.
That seems wrong. If the code targets Java 8, it must be possible to
test it using Java 8.
It's possibly OK to require
On Wed, 9 Jun 2021 at 17:03, John Patrick wrote:
> Have you tried "9" instead of "1.9"?
>
I've corrected that in the pom, thanks.
I think the issue is that Gilles used JDK 8 to try and build it. You can
run using the project's main artifacts using JDK 8, but the build now
requires JDK 9 for the
aven.compiler.target
have been replaced with maven.compiler.release. Not sure if the test
versions also changed or not.
I've no zero luck with a single pom with multiple src/test/java
directories, using different jdk's. The compiler supports toolchain
but when I last tried only for src
Hi.
"Commons Numbers" POM of module "commons-numbers-core"
contains
---CUT---
1.9
1.9
---CUT---
Running
$ JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn test site site:stage
fails:
---CUT---
[...]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-c
3, 2021, 22:13 Gary Gregory wrote:
> > >
> > >> Hi All:
> > >>
> > >> If you feel so inclined, I'd like help with
> > >> FastDateParserTest.java#testParsesKnownJava16Ea2
t;> Hi All:
> >>
> >> If you feel so inclined, I'd like help with
> >> FastDateParserTest.java#testParsesKnownJava16Ea25Failure().
> >>
> >> The test fails on Java 16 Early Access build 25 and a
g and it could be an
> issue in our code.
>
> Gary
>
> On Tue, Feb 23, 2021, 22:13 Gary Gregory wrote:
>
>> Hi All:
>>
>> If you feel so inclined, I'd like help with
>> FastDateParserTest.java#testParsesKnownJava16Ea25Failure().
>>
>> Th
re are also a
> couple test failures that are likely due to illegal reflective access.
> Case in point, one of the tests has an InaccessibleObject error
> message.
>
> Tested on:
>
> openjdk version "16" 2021-03-16
> OpenJDK Runtime Environment AdoptOpenJDK
Looks related to some locale changes most likely? There are also a
couple test failures that are likely due to illegal reflective access.
Case in point, one of the tests has an InaccessibleObject error
message.
Tested on:
openjdk version "16" 2021-03-16
OpenJDK Runtime Environment Ad
I'd like help with
> FastDateParserTest.java#testParsesKnownJava16Ea25Failure().
>
> The test fails on Java 16 Early Access build 25 and above, I am now
> testing with build
> 36.
>
> I cannot tell if this a bug in our code or in the underlying JRE.
>
> TY!
> Gary
>
Hi All:
If you feel so inclined, I'd like help with
FastDateParserTest.java#testParsesKnownJava16Ea25Failure().
The test fails on Java 16 Early Access build 25 and above, I am now
testing with build
36.
I cannot tell if this a bug in our code or in the underlying JRE.
TY!
a project.
>
> You should see a "Maven" tab and inside that tab see "Apache Commons Lang".
>
> Then expand commons-lang->src->test->java->org.apache.commons.lang3.
>
> Then right click or secondary click on the folder, then select "Run
> 'Test
Standard steps for a Maven project in IntelliJ...
a.k.a. open maven pom.xml in IntelliJ as a project.
You should see a "Maven" tab and inside that tab see "Apache Commons Lang".
Then expand commons-lang->src->test->java->org.apache.commons.lang3.
Then right
On 12/1/20 3:19 AM, Kanak Sony wrote:
Hey Developers,
I have been trying to debug the library in Intellij and in respect to that
trying to run test cases of Apache Commons Lang in intellij but I was
unable to find the same. Can anyone of you please suggest me if any such
resources are
Hey Developers,
I have been trying to debug the library in Intellij and in respect to that
trying to run test cases of Apache Commons Lang in intellij but I was
unable to find the same. Can anyone of you please suggest me if any such
resources are available?
--
Regards,
Kanak Sony
I was hoping to get some reviewers on this PR:
https://github.com/apache/commons-beanutils/pull/40
Basically it removes Commons Collections Test Framework 3.2.1 from
BeanUtils2 and simply copies a couple of classes it needs for the test.
The reason to get rid of Commons Collection Test
Thank you Alex!
Gary
On Sat, Oct 3, 2020, 02:51 Alex Herbert wrote:
>
>
> > On 3 Oct 2020, at 00:11, Gary Gregory wrote:
> >
> > -1
> > This is backward. Java 15 is the current version, not 14, and neither are
> > LTS. Please revert.
>
> My mistake. This has been reverted. Java 17 (Sept 2021)
> On 3 Oct 2020, at 00:11, Gary Gregory wrote:
>
> -1
> This is backward. Java 15 is the current version, not 14, and neither are
> LTS. Please revert.
My mistake. This has been reverted. Java 17 (Sept 2021) is the next slated LTS.
---
sitory https://gitbox.apache.org/repos/asf/commons-csv.git
>
> commit f7e34671c3d1a8b590b8ee8d0ff82b62579d80fa
> Author: Alex Herbert
> AuthorDate: Fri Oct 2 22:21:41 2020 +0100
>
> Test on Java LTS 14 and remove Java 15
>
> Java 15 is replaced by the experimental java 16-ea
>
on, Aug 24, 2020 at 9:47 AM Matt Sicker wrote:
> I like the test strategy they’re using at Mina: 8, latest LTS, and latest
> release. Those are the main supported lines of OpenJDK (from their
> distributors at least; I don’t think the project has official support), and
> since other
I like the test strategy they’re using at Mina: 8, latest LTS, and latest
release. Those are the main supported lines of OpenJDK (from their
distributors at least; I don’t think the project has official support), and
since other versions won’t receive updates, there’s not much point in
continued
Hi.
There exist a bug on jdk15, and which results a test failed on jdk15 for
commons-lang.
JDK guys said they will fix it on jdk16 but no plan for migrating the fix
to jdk15.
So maybe we should shut that test on jdk15, or we filter out some buggy
parts in that test and do not do it on jdk15?
Any
is that the CharSequence... will search for the first
> occurrence of any of the provided CharSequences. The single CharSequence
> arg-method will search for the first of any chars in the provided sequence.
>
> Regarding the test assertion:
> it's the index of *any *of the provi
The difference is that the CharSequence... will search for the first
occurrence of any of the provided CharSequences. The single CharSequence
arg-method will search for the first of any chars in the provided sequence.
Regarding the test assertion:
it's the index of *any *of the pro
Hi ~
I'm in the process of porting apache commons lang to scala, so it can
transpile to javascript/scala native. (
https://github.com/er1c/scala-apache-commons-lang3 FWIW)
One test I'm currently investigating is this line:
https://github.com/apache/commons-lang/blob/master/src/tes
ut.buffer.CircularBufferInputStreamTest.testRandomRead(CircularBufferInputStreamTest.java:51)
>
> I am guessing this commit:
>
> https://github.com/apache/commons-io/commit/a521b43e774a92f4c07461536ffc810715c762d8
>
>
> broke CI builds like:
>
> https://github.com/apach
CI builds are failing in CircularBufferInputStreamTest with:
[INFO] Running
org.apache.commons.io.input.buffer.CircularBufferInputStreamTest
[ERROR] Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
0.137 s <<< FAILURE! - in
org.apache.commons.io.input.buffer.CircularBufferInputStrea
bugs related to this were all address in 9).
> >
> > On Fri, Aug 7, 2020 at 12:03 sebb 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
> > >
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, a
> 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
, Aug 7, 2020 at 12:03 sebb 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&#
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 else
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
1 - 100 of 5178 matches
Mail list logo
