[VOTE] Releasing Orekit 10.2 from release candidate 2

Orekit development
1

This is a VOTE in order to release version 10.2 of the Orekit library.
Version 10.2 is a minor release.

Highlights in the 10.2 release are:

  • Support for CCSDS ADM files
  • Trajectories around Lagrangian point using CR3BP model
  • Time span drag force model
  • Time span tropospheric model
  • Estimated ionospheric model
  • Improved phase measurement
  • Several bug fixes for date functionalities
  • Configurable low thrust maneuver model based on detectors
  • Support for CSSI space weather data
  • New organization of the maneuvers package

The release candidate 1 can be found on the GitLab repository as tag 10.2-RC2 in the release-10.2 branch:
https://gitlab.orekit.org/orekit/orekit/tree/10.2-RC2

The release notes can be read here:
https://test.orekit.org/site-orekit-10.2/changes-report.html

Maven artifacts are available at:
https://oss.sonatype.org/content/repositories/orgorekit-1044/

The votes will be tallied in 120 hours for now, on 2020-07-12T14:30:00Z
(this is UTC time).

2

+1 for the release of Orekit 10.2

3

-1, sorry.

I get the following errors, running on a Linux machine running Debian, with openJDK and configured in French (i.e. the LANG environment variable is set to fr_FR.utf8):

[ERROR] Failures: 
[ERROR]   AbsoluteDateTest.testToString:1265->checkToString:1269 
Expected: is "2009-01-01T00:00:�"
     but: was "2009-01-01T00:00:NaN"
[ERROR]   AbsoluteDateTest.testToStringRfc3339:1159->check:1163 
Expected: is "2009-01-01T00:00:�Z"
     but: was "2009-01-01T00:00:NaNZ"

Looking at lines 1263-1265 of AbsoluteDateTest.java, it seems the unicode replacement character is expected to be used instead of NaN. However in my environment, the proper NaN string is emitted, not the replacement character. I guess it has something to do with the LANG settings.

4

Some more investigation on this. It is not a LANG issue but a JDK version issue.

The error occurs when using openJDK 11 or openJDK 13, but not when running openJDK 8.
On my Debian Linux machine, I can check this using the following command line that overrides some environment variables just for one command:

JAVA_PATH=/usr/lib/jvm/java-8-openjdk-amd64/ JAVA_HOME=$JAVA_PATH mvn surefire:test -Dtest=**/AbsoluteDateTest

I change the path to select one JDK over the other.

I think that the more recent JDK are correct (i.e. they display NaN as they should), and that some openJDK 8 implementations were wrong here, however, the test may have been set up using open JDK 8 as the reference.

Applying the attached patch solved the issue for me, for all three JDK version (8, 11 and 13). Could other developers check it?
date-test.patch (2.3 KB)

5

In the previous patch, the import java.util.Map statement should be removed.

6

The patch solved the problem for a
Java™ SE Runtime Environment (build 13.0.1+9)
And with an openJDK 8 (OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_252-b09)), it still works fine

7

Tested with openJDK 8. It works. Also tested with Java SE 14.0.1. It also works.

Is it ok to start RC3 ?

8

I guess RC3 can be started.

I’m really sorry for introducing this delay :worried:

9

It’s important to be alert to any source of problem :wink:

I start the production of RC3!

10

Vote for Release Candidate 2 is closed.

A new vote for Release Candidate 3 is opened here: