Re: [EXTERNAL] Re: [Numbers][All] Separate Java target version for "src/test"

[Alex Herbert]

I have removed the requirement for Java 9 from the build. It is still used
in the performance testing module.

Alex

Re: [EXTERNAL] Re: [Numbers][All] Separate Java target version for "src/test"

[Strauss, Randy (ARC-TI)[KBR Wyle Services, LLC]]

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 2021 at 17:56, sebb  wrote:
>
> > On Wed, 9 Jun 2021 at 17:26, Alex Herbert 
> > wrote:
> > >
> > > 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 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 9 for performance tests.
> >
>
> The test is using JDK 9 for the BigDecimal sqrt method. This is used to
> compute the exact answer for a Euclidean norm on random input. Since the
> input is random the answers cannot be hard-coded into the test. So this
> test is not possible on JDK 8. The alternative is if the exact computation
> is done using BigDecimal, converted to double, and then a sqrt computed. 
We
> could change to that instead if there are strong objections here against
> java 9.

I certainly object.

>
> The issue with requiring a higher JDK than the target is similar to using
> JDK 8 so that JUnit 5 can be used for the test suite to test code that
> targets a level lower than 1.8.

IMO that would be wrong as well.

Someone wanting to use the source on its minimum supported version
must be able to run the tests using that same version.

> Alex

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Numbers][All] Separate Java target version for "src/test"

[sebb]

On Wed, 9 Jun 2021 at 19:58, Alex Herbert  wrote:
>
> On Wed, 9 Jun 2021 at 17:56, sebb  wrote:
>
> > On Wed, 9 Jun 2021 at 17:26, Alex Herbert 
> > wrote:
> > >
> > > 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 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 9 for performance tests.
> >
>
> The test is using JDK 9 for the BigDecimal sqrt method. This is used to
> compute the exact answer for a Euclidean norm on random input. Since the
> input is random the answers cannot be hard-coded into the test. So this
> test is not possible on JDK 8. The alternative is if the exact computation
> is done using BigDecimal, converted to double, and then a sqrt computed. We
> could change to that instead if there are strong objections here against
> java 9.

I certainly object.

>
> The issue with requiring a higher JDK than the target is similar to using
> JDK 8 so that JUnit 5 can be used for the test suite to test code that
> targets a level lower than 1.8.

IMO that would be wrong as well.

Someone wanting to use the source on its minimum supported version
must be able to run the tests using that same version.

> Alex

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Numbers][All] Separate Java target version for "src/test"

[Gilles Sadowski]

Le mer. 9 juin 2021 à 20:58, Alex Herbert  a écrit :
>
> On Wed, 9 Jun 2021 at 17:56, sebb  wrote:
>
> > On Wed, 9 Jun 2021 at 17:26, Alex Herbert 
> > wrote:
> > >
> > > 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 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 9 for performance tests.

IIRC, the explicit setting of "JAVA_HOME" was intended to ensure
that the binaries are created with the correct bytecode version.

So, indeed,
$ JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn test site site:stage
does not work with "9" either.

Should we just skip this "validation" test (and solely rely on the compiler
settings in the POM being correct)?


Gilles

>
> The test is using JDK 9 for the BigDecimal sqrt method. This is used to
> compute the exact answer for a Euclidean norm on random input. Since the
> input is random the answers cannot be hard-coded into the test. So this
> test is not possible on JDK 8. The alternative is if the exact computation
> is done using BigDecimal, converted to double, and then a sqrt computed. We
> could change to that instead if there are strong objections here against
> java 9.
>
> The issue with requiring a higher JDK than the target is similar to using
> JDK 8 so that JUnit 5 can be used for the test suite to test code that
> targets a level lower than 1.8.
>
> Alex

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Numbers][All] Separate Java target version for "src/test"

[Alex Herbert]

On Wed, 9 Jun 2021 at 17:56, sebb  wrote:

> On Wed, 9 Jun 2021 at 17:26, Alex Herbert 
> wrote:
> >
> > 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 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 9 for performance tests.
>

The test is using JDK 9 for the BigDecimal sqrt method. This is used to
compute the exact answer for a Euclidean norm on random input. Since the
input is random the answers cannot be hard-coded into the test. So this
test is not possible on JDK 8. The alternative is if the exact computation
is done using BigDecimal, converted to double, and then a sqrt computed. We
could change to that instead if there are strong objections here against
java 9.

The issue with requiring a higher JDK than the target is similar to using
JDK 8 so that JUnit 5 can be used for the test suite to test code that
targets a level lower than 1.8.

Alex

Re: [Numbers][All] Separate Java target version for "src/test"

[sebb]

On Wed, 9 Jun 2021 at 17:26, Alex Herbert  wrote:
>
> 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 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 9 for performance tests.

> I've
> successfully used JDK 9 and JDK 11 for the build.
>
> Travis CI is using JDK 11 and the Jenkins server is using JDK 9 for the
> main build and JDK 11 for the sonarcloud analysis build.
>
> Alex

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Numbers][All] Separate Java target version for "src/test"

[Alex Herbert]

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 tests and JMH performance tests. I've
successfully used JDK 9 and JDK 11 for the build.

Travis CI is using JDK 11 and the Jenkins server is using JDK 9 for the
main build and JDK 11 for the sonarcloud analysis build.

Alex

Re: [Numbers][All] Separate Java target version for "src/test"

[John Patrick]

Have you tried "9" instead of "1.9"?
I believe the 1.x was dropped with Java 9's release.
Also might want to bump it to Java 11 as that is a LTS release, as 9
was only supported for 6 months from september 2017 to march 2018.

Also with 9 and newer, maven.compiler.source/maven.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/main directories, not for src/test
directories.

Also when the tests run they see everything in target/test-classes so
do you run them with 1.8 or 9?

JEP 238 supports multiple java versions in a single jar, but last time
i tried it appears to have a bug that the base version has to be java
9.

Not sure if the above helps or not, or give any insight.

John

On Wed, 9 Jun 2021 at 15:29, Gilles Sadowski  wrote:
>
> 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-compiler-plugin:3.8.1:testCompile
> (default-testCompile) on project commons-numbers-core: Fatal error
> compiling: invalid target release: 1.9 -> [Help 1]
> ---CUT---
>
> Regards,
> Gilles
>
> -
> 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: [Math] CI builds are missing problems

[Alex Herbert]

On Wed, 9 Jun 2021 at 16:04, Gilles Sadowski  wrote:

> Le mer. 9 juin 2021 à 16:07, Alex Herbert  a
> écrit :
> >
> > The math project does not build with the default goal in the pom:
> >
> > clean verify apache-rat:check checkstyle:check pmd:check spotbugs:check
> > javadoc:javadoc
> >
> > There is a spotbugs error in the Artificial neural networks module due
> to a
> > case statement fall through. This is intentional so I added an
> exclusion. I
> > then get failures later on and have not fixed them all.
>
> The default build now stops at two SpotBugs issues in "AccurateMath";
> they relate to two magic numbers that are close to pi / 2.
>

I think these are intentional. The numbers are used when correcting values
in the domain close to [-pi, pi].

I've fixed a few errors in the new modules, which now build locally. There
are 36 errors in legacy. I am looking at these. Perhaps it is best to just
disable spotbugs for the legacy module.

Alex

Re: [Math] CI builds are missing problems

[Gilles Sadowski]

Le mer. 9 juin 2021 à 16:07, Alex Herbert  a écrit :
>
> The math project does not build with the default goal in the pom:
>
> clean verify apache-rat:check checkstyle:check pmd:check spotbugs:check
> javadoc:javadoc
>
> There is a spotbugs error in the Artificial neural networks module due to a
> case statement fall through. This is intentional so I added an exclusion. I
> then get failures later on and have not fixed them all.

The default build now stops at two SpotBugs issues in "AccurateMath";
they relate to two magic numbers that are close to pi / 2.

Gilles

>
> Travis current uses the default script [1]:
>
> mvn test -B
>
> Jenkins uses this goal:
>
> -e -V clean deploy --batch-mode -Dgpg.skip -Prelease
>
> So neither CI environment is using the default goal and problems have gone
> unchecked.
>
> I suggest fixing the build for the default goal and then updating travis to
> use it:
>
> script:
>  - mvn
>
> Alex
>
>
> [1] https://docs.travis-ci.com/user/languages/java/

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Problems building Commons Math4 Legacy

[Gilles Sadowski]

Le mer. 9 juin 2021 à 16:10, Alex Herbert  a écrit :
>
> On Wed, 9 Jun 2021 at 15:02, Gilles Sadowski  wrote:
>
> > Le mer. 9 juin 2021 à 15:58, Alex Herbert  a
> > écrit :
> > >
> > I'm doing it...
> >
>
> OK. I was trying to fix the math build using the default maven goal.
> Currently there are issues. See separate e-mail thread on the CI build
> goals.
>
> I've pushed the spotbugs exclusion and I will wait until you are done.

Done.

>
> Alex

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[Numbers][All] Separate Java target version for "src/test"

[Gilles Sadowski]

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-compiler-plugin:3.8.1:testCompile
(default-testCompile) on project commons-numbers-core: Fatal error
compiling: invalid target release: 1.9 -> [Help 1]
---CUT---

Regards,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Problems building Commons Math4 Legacy

[Alex Herbert]

On Wed, 9 Jun 2021 at 15:02, Gilles Sadowski  wrote:

> Le mer. 9 juin 2021 à 15:58, Alex Herbert  a
> écrit :
> >
> I'm doing it...
>

OK. I was trying to fix the math build using the default maven goal.
Currently there are issues. See separate e-mail thread on the CI build
goals.

I've pushed the spotbugs exclusion and I will wait until you are done.

Alex

[Math] CI builds are missing problems

[Alex Herbert]

The math project does not build with the default goal in the pom:

clean verify apache-rat:check checkstyle:check pmd:check spotbugs:check
javadoc:javadoc

There is a spotbugs error in the Artificial neural networks module due to a
case statement fall through. This is intentional so I added an exclusion. I
then get failures later on and have not fixed them all.

Travis current uses the default script [1]:

mvn test -B

Jenkins uses this goal:

-e -V clean deploy --batch-mode -Dgpg.skip -Prelease

So neither CI environment is using the default goal and problems have gone
unchecked.

I suggest fixing the build for the default goal and then updating travis to
use it:

script:
 - mvn

Alex


[1] https://docs.travis-ci.com/user/languages/java/

Re: [math] Problems building Commons Math4 Legacy

[Gilles Sadowski]

Le mer. 9 juin 2021 à 15:58, Alex Herbert  a écrit :
>
> On Wed, 9 Jun 2021 at 14:55, Gilles Sadowski  wrote:
>
> > Hello.
> >
> > Le mer. 9 juin 2021 à 15:49, Erik Svensson  a
> > écrit :
> > >
> > > Hi!
> > >
> > >
> > >
> > > I’m trying and failing to build commons-math and it looks like the class
> > LinearCombination is either in the wrong package.
> > >
> > > In DerivativeStructure for instance, LinearCombination is declared as
> > org.apache.commons.numbers.arrays.LinearCombination instead of
> > org.apache.commons.numbers.core.LinearCombination.
> > >
> > > I think I have pulled the last from master so I’m a bit stumped.
> > >
> > > Is fixing this (in some way) something that is in the works
> >
> > Yes; sorry for the inconvenience.
> > This part of the "Commons Numbers" API has been undergoing
> > changes in the last 12 hours.
> >
> > > or should I do something?
> >
> > No.  Hopefully it'll soon come back to normal.
> > This glitch will probably reoccur with
> > https://issues.apache.org/jira/browse/NUMBERS-162
>
>
> The maths project is using snapshot dependencies on commons numbers as it
> is currently not released.
>
> This class has recently been updated. It was moved to a different
> package and the method names have been updated.
>
> I will fix master when the latest snapshot of number has been deployed to
> the snapshot repo.

I'm doing it...

Gilles

>
> Alex
>
>
> >
> >
> > Regards,
> > Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Problems building Commons Math4 Legacy

[Alex Herbert]

On Wed, 9 Jun 2021 at 14:55, Gilles Sadowski  wrote:

> Hello.
>
> Le mer. 9 juin 2021 à 15:49, Erik Svensson  a
> écrit :
> >
> > Hi!
> >
> >
> >
> > I’m trying and failing to build commons-math and it looks like the class
> LinearCombination is either in the wrong package.
> >
> > In DerivativeStructure for instance, LinearCombination is declared as
> org.apache.commons.numbers.arrays.LinearCombination instead of
> org.apache.commons.numbers.core.LinearCombination.
> >
> > I think I have pulled the last from master so I’m a bit stumped.
> >
> > Is fixing this (in some way) something that is in the works
>
> Yes; sorry for the inconvenience.
> This part of the "Commons Numbers" API has been undergoing
> changes in the last 12 hours.
>
> > or should I do something?
>
> No.  Hopefully it'll soon come back to normal.
> This glitch will probably reoccur with
> https://issues.apache.org/jira/browse/NUMBERS-162


The maths project is using snapshot dependencies on commons numbers as it
is currently not released.

This class has recently been updated. It was moved to a different
package and the method names have been updated.

I will fix master when the latest snapshot of number has been deployed to
the snapshot repo.

Alex


>
>
> Regards,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [math] Problems building Commons Math4 Legacy

[Gilles Sadowski]

Hello.

Le mer. 9 juin 2021 à 15:49, Erik Svensson  a écrit :
>
> Hi!
>
>
>
> I’m trying and failing to build commons-math and it looks like the class 
> LinearCombination is either in the wrong package.
>
> In DerivativeStructure for instance, LinearCombination is declared as 
> org.apache.commons.numbers.arrays.LinearCombination instead of 
> org.apache.commons.numbers.core.LinearCombination.
>
> I think I have pulled the last from master so I’m a bit stumped.
>
> Is fixing this (in some way) something that is in the works

Yes; sorry for the inconvenience.
This part of the "Commons Numbers" API has been undergoing
changes in the last 12 hours.

> or should I do something?

No.  Hopefully it'll soon come back to normal.
This glitch will probably reoccur with
https://issues.apache.org/jira/browse/NUMBERS-162

Regards,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[math] Problems building Commons Math4 Legacy

[Erik Svensson]

Hi!

I’m trying and failing to build commons-math and it looks like the class 
LinearCombination is either in the wrong package.
In DerivativeStructure for instance, LinearCombination is declared as 
org.apache.commons.numbers.arrays.LinearCombination instead of 
org.apache.commons.numbers.core.LinearCombination.
I think I have pulled the last from master so I’m a bit stumped.
Is fixing this (in some way) something that is in the works or should I do 
something?

Cheers


Erik Svensson
Principal Architect
Strategic Programs, Platform & Product Engineering

[Nasdaq, Inc.]

Desk
Mobile
Email
Address

+ 46 8 405 66 39
+ 46 73 449 66 39
erik.svens...@nasdaq.com
Tullvaktsvägen 15, Stockholm


[signature_1397800798]

[signature_1424503647]

[signature_1369595666]

[signature_1267502779]

[signature_696719070]


rewritetomorrow.com


***
CONFIDENTIALITY AND PRIVACY NOTICE: This e-mail and any attachments are for the 
exclusive and confidential use of the intended recipient and may constitute 
non-public information.  Personal data in this email is governed by our Privacy 
Policy at  https://www.nasdaq.com/privacy-statement  unless explicitly excluded 
from it; please see the section in the policy entitled “Situations Where This 
Privacy Policy Does Not Apply” for circumstances where different privacy terms 
govern emailed personal data.  If you received this e-mail in error, 
disclosing, copying, distributing or taking any action in reliance of this 
e-mail is strictly prohibited and may be unlawful. Instead, please notify us 
immediately by return e-mail and promptly delete this message and its 
attachments from your computer system. We do not waive any work product or 
other applicable legal privilege(s) by the transmission of this message.
***