Orekit issueshttps://gitlab.orekit.org/orekit/orekit/-/issues2019-07-05T17:41:54Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/389Change type parameter of AbstractDetector to T extends AbstractDetector<T>2019-07-05T17:41:54ZEvan WardChange type parameter of AbstractDetector to T extends AbstractDetector<T>If the user knows they have an AbstractDetector, they should be able to
call the withXxx methods any number of times.
Currently the following fails to compile because the type returned by
the withXxx() methods is an EventDetector
\`\`...If the user knows they have an AbstractDetector, they should be able to
call the withXxx methods any number of times.
Currently the following fails to compile because the type returned by
the withXxx() methods is an EventDetector
\`\`\`
AbstractDetector<?>d = ...;
d.withMaxIter(9).withMaxIter(9);
\`\`\`
To call the with methods multiple times you have replace \`?\` with \`?
extends AbstractDetector<?>\` once for each time you plan to call
a with method. Clearly this does not scale well and is bad API design.
Changing the declaration of AbstractDetector to
\`AbstractDetector<T extends AbstractDetector<T>>\` would solve the
issue and allow the earlier example to compile.
This change is backwards incompatible, so I'm making a note of it here
util we are ready to include it.
*(from redmine: issue id 389, created on 2018-03-07)*10.0https://gitlab.orekit.org/orekit/orekit/-/issues/506Delete FieldEventHandler.Action2019-07-05T17:41:50ZEvan WardDelete FieldEventHandler.Action`FieldEventHandler.Action` just duplicates `EventHandler.Action` without adding any field specific behavior or information. Remove the duplicate enum and just use `EventHandler.Action`. It may be worth moving `Action` to a top level type...`FieldEventHandler.Action` just duplicates `EventHandler.Action` without adding any field specific behavior or information. Remove the duplicate enum and just use `EventHandler.Action`. It may be worth moving `Action` to a top level type to clarify it can be used for field and non-field event detectors. Hipparchus only uses one Action enum for both double and Field ODEs. This change will break backward compatibility, so it should wait until the next major release.
Other option is to delete both of Orekit's Action enums and just use Action from Hipparchus since they must all define the same values for Orekit to work correctly.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/507Add Action.RESET_EVENTS2019-07-05T17:42:38ZEvan WardAdd Action.RESET_EVENTSAdd an event action that tells the propagator to recheck all event detectors for occurring events.
See the discussion in https://forum.orekit.org/t/eventdetection-based-on-time-in/293Add an event action that tells the propagator to recheck all event detectors for occurring events.
See the discussion in https://forum.orekit.org/t/eventdetection-based-on-time-in/29310.0https://gitlab.orekit.org/orekit/orekit/-/issues/514Deprecate then delete unused DerivativeStructure acceleration computation met...2019-07-05T17:41:52ZMaxime JournotDeprecate then delete unused DerivativeStructure acceleration computation methodsSome methods computing `FieldVector3D<DerivativeStructure>` acceleration and using a parameter name as input should have been deleted in version 9.0 but were left over.
They should be deemed `@Deprecated` in version 9.3 and then deleted ...Some methods computing `FieldVector3D<DerivativeStructure>` acceleration and using a parameter name as input should have been deleted in version 9.0 but were left over.
They should be deemed `@Deprecated` in version 9.3 and then deleted in version 10.0.
These methods are:
- `FieldVector3D<DerivativeStructure> dragAcceleration` in interface [DragSensitive](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/forces/drag/DragSensitive.java#L117) and all its implementations;
- `FieldVector3D<DerivativeStructure> radiationPressureAcceleration` in [RadiationSensitive](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/forces/radiation/RadiationSensitive.java#L90) and all its implementations
Related tests should also be deprecated then deleted.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/518AbstractGNSSAttitudeProvider should be private package2019-07-05T17:41:50ZPetrus HyvönenAbstractGNSSAttitudeProvider should be private packageThe AbstractGNSSAttitudeProvider is not usable outside the attitude package and was not intented (ref Luc) for public usage. This package should thus be set private.The AbstractGNSSAttitudeProvider is not usable outside the attitude package and was not intented (ref Luc) for public usage. This package should thus be set private.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/519Add GLONASS Propagator2019-07-05T17:41:53ZBryan CazabonneAdd GLONASS PropagatorAs it is already done in Orekit for GPS orbits, it can be interesting to add a Glonass propagator to convert Glonass almanac data to position and velocity vector components.
Steps of computation are present into [GLONASS Interface Contr...As it is already done in Orekit for GPS orbits, it can be interesting to add a Glonass propagator to convert Glonass almanac data to position and velocity vector components.
Steps of computation are present into [GLONASS Interface Control Document](http://gauss.gge.unb.ca/GLONASS.ICD.pdf)10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/520Add Galileo Propagator2019-07-05T17:41:52ZBryan CazabonneAdd Galileo PropagatorSame as issue #519 but for Galileo almanacs.
Steps of computations are available into [Galileo Interface Control Document](https://www.gsc-europa.eu/system/files/galileo_documents/Galileo-OS-SIS-ICD.pdf)Same as issue #519 but for Galileo almanacs.
Steps of computations are available into [Galileo Interface Control Document](https://www.gsc-europa.eu/system/files/galileo_documents/Galileo-OS-SIS-ICD.pdf)10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/521Add BeiDou Propagator2019-07-05T17:41:53ZBryan CazabonneAdd BeiDou PropagatorSame as issue #519 and #520 but for BeiDou satellites.
Steps of computation are detailed into [BeiDou Interface Control Document](http://en.beidou.gov.cn/SYSTEMS/Officialdocument/201806/P020180608525875134604.pdf)Same as issue #519 and #520 but for BeiDou satellites.
Steps of computation are detailed into [BeiDou Interface Control Document](http://en.beidou.gov.cn/SYSTEMS/Officialdocument/201806/P020180608525875134604.pdf)10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/522Add QZSS Propagator2019-07-05T17:41:53ZBryan CazabonneAdd QZSS PropagatorSee issues #519 #520 #521
Steps of computation are available on the [QZSS Interface Specification](http://qzss.go.jp/en/technical/download/pdf/ps-is-qzss/is-qzss-pnt-003.pdf?t=1549268771755)See issues #519 #520 #521
Steps of computation are available on the [QZSS Interface Specification](http://qzss.go.jp/en/technical/download/pdf/ps-is-qzss/is-qzss-pnt-003.pdf?t=1549268771755)10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/526Remove private class BilinearInterpolatingFunction into Saastamoinen model2019-07-05T17:42:39ZBryan CazabonneRemove private class BilinearInterpolatingFunction into Saastamoinen modelBilinearInterpolatingFunction is available into Hipparchus since release 1.4. Hence, it is possible to replace the private class BilinearInterpolatingFunction of the Saastamoinen model by the one of Hipparchus.BilinearInterpolatingFunction is available into Hipparchus since release 1.4. Hence, it is possible to replace the private class BilinearInterpolatingFunction of the Saastamoinen model by the one of Hipparchus.10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/527SI base unit API for magnetic field model2019-07-05T17:41:53ZBryan CazabonneSI base unit API for magnetic field modelCurrent API for magnetic field model is not in SI base unit. Magnetic field is computed using latitude and longitude in degrees and height in kilometers as input parameters. Furthermore, `getDeclination()` and `getInclination()` methods ...Current API for magnetic field model is not in SI base unit. Magnetic field is computed using latitude and longitude in degrees and height in kilometers as input parameters. Furthermore, `getDeclination()` and `getInclination()` methods in `GeoMagneticElements.java` class return angles in degree unit. API has to be change to consider angles in radians and height in meters.10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/528getClockCorrection from SP3File returns value in megaseconds2019-07-05T17:42:39ZGowtham SivaramangetClockCorrection from SP3File returns value in megasecondsWhen trying to load clock corrections value using `SP3Parser` from an sp3 file, the value returned by `getClockCorrection` is in megaseconds, although the document specifies seconds.
During parsing of SP3 file, `latestClock` is multipl...When trying to load clock corrections value using `SP3Parser` from an sp3 file, the value returned by `getClockCorrection` is in megaseconds, although the document specifies seconds.
During parsing of SP3 file, `latestClock` is multiplied by 1E6 instead of 1E-6. Similarly issue exists for `clockRateChange` also.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/529Attitude transitions in analytical propagators2019-07-05T17:42:40ZMirco RasottoAttitude transitions in analytical propagatorsWhen trying to use the attitude sequence with an Ephemeris object, an OUT_OF_RANGE_SIMPLE exception is thrown.When trying to use the attitude sequence with an Ephemeris object, an OUT_OF_RANGE_SIMPLE exception is thrown.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/530Removing Serializable for events detectors and attitude providers2019-06-14T20:00:01ZLuc MaisonobeRemoving Serializable for events detectors and attitude providersAs per discussion [https://forum.orekit.org/t/removing-serializable-for-events-detectors-and-perhaps-attitude-providers/403](https://forum.orekit.org/t/removing-serializable-for-events-detectors-and-perhaps-attitude-providers/403), seria...As per discussion [https://forum.orekit.org/t/removing-serializable-for-events-detectors-and-perhaps-attitude-providers/403](https://forum.orekit.org/t/removing-serializable-for-events-detectors-and-perhaps-attitude-providers/403), serialization should be removed for at least event detectors and attitude providers.10.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/531Remove TroposphericModel interface2019-07-05T17:41:52ZBryan CazabonneRemove TroposphericModel interfaceSince Orekit 9.3, a new interface is available for tropospheric models (`DiscreteTroposphericModel`).
Because of compatibility issues, we did not delete the interface `TroposphericModel` for Orekit 9.3 release. Major release allowing API...Since Orekit 9.3, a new interface is available for tropospheric models (`DiscreteTroposphericModel`).
Because of compatibility issues, we did not delete the interface `TroposphericModel` for Orekit 9.3 release. Major release allowing API changes it is possible for Orekit 10.0 release to delete this interface. Implementations of the old interface `TroposphericModel` should now implement `DiscreteTroposphericModel`.10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/532Add Shapiro effect2019-06-14T19:59:46ZLuc MaisonobeAdd Shapiro effectFor very accurate (centimeter level) range measurements, the relativistic Shapiro effect
should be considered.For very accurate (centimeter level) range measurements, the relativistic Shapiro effect
should be considered.10.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/538Problem with method ComparableMeasurement.compareTo()2019-07-05T17:42:40ZDorian GegoutProblem with method ComparableMeasurement.compareTo()It seems there is a bug the method ComparableMeasurement.compareTo() which allow violation of the transitivity rule. Further details are explained on https://forum.orekit.org/t/problem-with-method-comparablemeasurement-compareto/438It seems there is a bug the method ComparableMeasurement.compareTo() which allow violation of the transitivity rule. Further details are explained on https://forum.orekit.org/t/problem-with-method-comparablemeasurement-compareto/43810.0https://gitlab.orekit.org/orekit/orekit/-/issues/539Deprecated day of year computation in DTM2000 model.2019-07-05T17:42:36ZMaxime JournotDeprecated day of year computation in DTM2000 model.DTM2000 atmosphere class uses Java class GregorianCalendar in method [getDensity](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/forces/drag/atmosphere/DTM2000.java#L333) to compute the day of year.
No Tim...DTM2000 atmosphere class uses Java class GregorianCalendar in method [getDensity](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/forces/drag/atmosphere/DTM2000.java#L333) to compute the day of year.
No TimeZone is provided so that the default TimeZone is used. Default TimeZone depends on user's machine so it can be different than "GMT+00".
Day of year computation should not be dependent on user's default time zone.
Method [DateComponents.getDayOfYear](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/time/DateComponents.java#L447) should be used instead (as in [NRLMSIS00.getDensity](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/forces/drag/atmosphere/NRLMSISE00.java#L1127)).10.0https://gitlab.orekit.org/orekit/orekit/-/issues/541README enhancement2019-07-05T17:42:35ZSébastien Dinotsebastien.dinot@csgroup.euREADME enhancementIn my humble opinion, the [README file](https://gitlab.orekit.org/orekit/orekit/blob/master/README.txt) provided with Orekit source code is totally old-fashioned:
* It uses the plain text format rather than a lightweight markup language...In my humble opinion, the [README file](https://gitlab.orekit.org/orekit/orekit/blob/master/README.txt) provided with Orekit source code is totally old-fashioned:
* It uses the plain text format rather than a lightweight markup language such as [Markdown](https://daringfireball.net/projects/markdown/) or [reStructuredText](http://docutils.sourceforge.net/rst.html).
* It is poor in information (no indication is provided, for example, on how to contribute, or how to report a bug).
Several initiatives have attempted to list good practices regarding the content of a README file and/or to provide README templates:
* [Readme Best Practices](https://github.com/jehna/readme-best-practices)
* [Art of README](https://github.com/noffle/art-of-readme)
I think that Orekit merits such modern README file.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/543Hang via crafted itrf-versions.conf2019-07-05T17:41:52ZEvan WardHang via crafted itrf-versions.confI was playing around with the new itrf-versions.conf and noticed that any regular expression (RE) is accepted. If the file is loaded from an un-trusted source this can hang the application because Java's REs can take exponential time to ...I was playing around with the new itrf-versions.conf and noticed that any regular expression (RE) is accepted. If the file is loaded from an un-trusted source this can hang the application because Java's REs can take exponential time to halt.[1] One one hand supplemental data should only be loaded from trusted sources to ensure the accuracy of computations. On the other hand one could argue that the effects of loading un-trusted data shouldn't be any worse than inaccurate results. So I'm not decided if it is a security issue or not. The thing that makes me nervous is that Orekit can load these files from the internet. What do you think? @luc
For example, I have a `itrf-versions.conf` file that contains:
```
f(.+)+.{40} ------ ------ ITRF-2005
```
And a EOP file named `finals2000A.0reallyloooooooooooooooooooonName`. With these settings Orekit has been hung since yesterday. It seems the file name needs to be longer than about 20 characters to cause issues.
Possible Solutions:
1. Document it and warn the user so they can take appropriate steps to only load trusted data.
2. Use a different RE implementation than Java's Matcher. It is possible to match the above RE in roughly linear time, but Java's implementation of RE is extended to include non-regular expressions such as back references which necessitates the slower algorithm.
3. Implement a watchdog, though I'm not sure if RE matching is interruptible.
4. others?
[1] https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS10.0Evan WardEvan Wardhttps://gitlab.orekit.org/orekit/orekit/-/issues/544Infinite loop on GPSPropagator and (Field)KeplerianOrbit2019-07-05T17:42:35ZBryan CazabonneInfinite loop on GPSPropagator and (Field)KeplerianOrbitA pull request has been open on the Orekit GitHub repository ([here](https://github.com/CS-SI/Orekit/pull/21#issuecomment-489652905)). It is related to an endless loop when `x.getValue()` or `x0.getValue()` is Double.NaN on GPSPropagator...A pull request has been open on the Orekit GitHub repository ([here](https://github.com/CS-SI/Orekit/pull/21#issuecomment-489652905)). It is related to an endless loop when `x.getValue()` or `x0.getValue()` is Double.NaN on GPSPropagator class. This endless loop can also occur on KeplerianOrbit and FieldKeplerianOrbit classes.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/545.mailmap file is out of date2019-07-05T17:42:36ZSébastien Dinotsebastien.dinot@csgroup.eu.mailmap file is out of dateThe [.mailmap](https://gitlab.orekit.org/orekit/orekit/blob/develop/.mailmap) file is quite out of date. As it stands, Orekit seems to have been developed by 49 different people, but in reality, the project has only 33 contributors.
The...The [.mailmap](https://gitlab.orekit.org/orekit/orekit/blob/develop/.mailmap) file is quite out of date. As it stands, Orekit seems to have been developed by 49 different people, but in reality, the project has only 33 contributors.
The merge request !4 is proposed to fix this issue.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/546Update pom.xml to Hipparchus 1.52019-07-05T17:41:51ZMaxime JournotUpdate pom.xml to Hipparchus 1.5Hipparchus 1.5 was released a week ago.
We can now update the pom.xml of Orekit.Hipparchus 1.5 was released a week ago.
We can now update the pom.xml of Orekit.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/548Organization of the models package2019-07-05T17:41:51ZBryan CazabonneOrganization of the models packageA discussion has been open in the [forum](https://forum.orekit.org/t/package-organization-in-orekit/472) for this enhancement. The goal is to have a clean organization by adding sub-packages for ionospheric, tropospheric and global weath...A discussion has been open in the [forum](https://forum.orekit.org/t/package-organization-in-orekit/472) for this enhancement. The goal is to have a clean organization by adding sub-packages for ionospheric, tropospheric and global weather models.10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/549Eclipse Detector: Re-add the getters and delete deprecated constructors ?2019-07-05T17:41:50ZMaxime JournotEclipse Detector: Re-add the getters and delete deprecated constructors ?In [EclipseDetector](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/propagation/events/EclipseDetector.java) class, recent changes (see [#535](https://gitlab.orekit.org/orekit/orekit/issues/535)) have:
1. ...In [EclipseDetector](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/propagation/events/EclipseDetector.java) class, recent changes (see [#535](https://gitlab.orekit.org/orekit/orekit/issues/535)) have:
1. Removed the getters for the occulted and occulting body;
1. Lead to the deprecation of constructor based on a spherical occulting body.
For version 10.0 shall we ?
1. Write back some getters. They can be useful when multiple EclipseDetectors are used and we want to discriminate between them.
Example: Set up 2 EclipseDetectors for Sun occultation, one with the Earth and the other one with the Moon as the occulting body.
Use an event logger to log the events.
After propagation, how can we distinguish between Earth eclipses and Moon eclipses if we don't have access to the occulting body name ?
Maybe there is another way to do it but I don't know how...
1. Delete the deprecated constructors and the inner class `SphericalOccultingBody`.
Though it seems ok to me to keep the older constructors for users that just want to use "simple" spherical-based occultation.
On the other hand we could simply document how to use a spherical body, as @luc explains it in issue #535.
What do you think ?10.0https://gitlab.orekit.org/orekit/orekit/-/issues/550Download url of the latest Orekit archives not provided in technical document...2019-07-05T17:42:37ZSébastien Dinotsebastien.dinot@csgroup.euDownload url of the latest Orekit archives not provided in technical documentationDownload url of the latest Orekit archives not provided in the technical documentation generated by Maven:
<https://www.orekit.org/site-orekit-9.3.1/downloads.html>
---
| package | link ...Download url of the latest Orekit archives not provided in the technical documentation generated by Maven:
<https://www.orekit.org/site-orekit-9.3.1/downloads.html>
---
| package | link |
|----------|---------------------------------------------------------------------|
| source | orekit-9.3.1-sources.zip (URL to be defined after official release) |
| binary | orekit-9.3.1.jar (URL to be defined after official release) |
version 9.3.1 downloads (release date: 2019-03-16)
---10.0https://gitlab.orekit.org/orekit/orekit/-/issues/551AttitudeSequence transition not computed with analytical propagators2019-07-05T17:42:37ZRomaric HERAttitudeSequence transition not computed with analytical propagatorsIn the case of an attitude transition is triggered by an event detector during an analytical propagation, the attitude of the satellite is not correctly computed if the beginning of the propagation is before the transition and the end of...In the case of an attitude transition is triggered by an event detector during an analytical propagation, the attitude of the satellite is not correctly computed if the beginning of the propagation is before the transition and the end of the propagation is after the transition.
The origin of the bug is : the final SpacecraftState is computed before the event triggering, but the attitude transition is computed only after the events triggering. So the returned SpacecraftState is computed with the initial attitude law, not the updated one after the transition.10.0Romaric HERRomaric HERhttps://gitlab.orekit.org/orekit/orekit/-/issues/552AttitudeSequence bug when the propagation ends and restart during the transit...2019-07-05T17:42:37ZRomaric HERAttitudeSequence bug when the propagation ends and restart during the transition periodIn case of multiple uses of the propagate method with an attitude sequence, if one use of propagate method ends in the transition period an another one starts during the transition period, the attitude after the transition is not correct...In case of multiple uses of the propagate method with an attitude sequence, if one use of propagate method ends in the transition period an another one starts during the transition period, the attitude after the transition is not correct.
This is due to the fact that each use of the propagate method reset the events detector, that reset the TimeSpanMap used in the AttitudeSequence object. The reset will cause that the map that is supposed to describe the "after" attitude law is deleted by the reset, since the current date is still in the transition period. But the transition event is already in the past so the "after" attitude law will not be computed again. The attitude law is stuck in the transition phase and returns wrong values.10.0Romaric HERRomaric HERhttps://gitlab.orekit.org/orekit/orekit/-/issues/553AttitudeSequence bug with Ephemeris propagator2019-07-05T17:42:36ZRomaric HERAttitudeSequence bug with Ephemeris propagatorIn case of an attitude transition during an propagation with Ephemeris, a "OUT_OF_RANGE_SIMPLE" exception will be thrown.
This is due to a check in the getPVCoordinates method of Ephemeris, that will check that the current date is the s...In case of an attitude transition during an propagation with Ephemeris, a "OUT_OF_RANGE_SIMPLE" exception will be thrown.
This is due to a check in the getPVCoordinates method of Ephemeris, that will check that the current date is the same as the computed state date. In case of an attitude transition, if we try to compute the attitude during the transition period, the propagator needs the attitude at the end of this period, so this check will fail.10.0Romaric HERRomaric HERhttps://gitlab.orekit.org/orekit/orekit/-/issues/554Merge branch "propagation-in-inertial-frame" into "develop"2019-07-05T17:41:51ZMaxime JournotMerge branch "propagation-in-inertial-frame" into "develop"The `propagation-in-inertial-frame` branch has been living its life on its own since 4 years now.
As we're on the verge of releasing a major version, it is time to merge it on the `develop` branch.The `propagation-in-inertial-frame` branch has been living its life on its own since 4 years now.
As we're on the verge of releasing a major version, it is time to merge it on the `develop` branch.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/556Coverage results not taken into account in the CI build status2019-07-05T17:42:38ZSébastien Dinotsebastien.dinot@csgroup.euCoverage results not taken into account in the CI build statusThe CI build status of [Build #127](https://ci.orekit.org/job/orekit/job/develop/127/) displayed by Jenkins is "Success" (blue bullet) despite that the coverage ratios are under the required values:
* Class: 99 % instead of 100 %
* Meth...The CI build status of [Build #127](https://ci.orekit.org/job/orekit/job/develop/127/) displayed by Jenkins is "Success" (blue bullet) despite that the coverage ratios are under the required values:
* Class: 99 % instead of 100 %
* Method: 93 % instead of 95 %
The CI tool should warn developers against such deviation and display a different result (yellow or red bullet depending on the coverage ratios are under "maximum<Counter>Coverage" or "minimun<Counter>Coverage").10.0https://gitlab.orekit.org/orekit/orekit/-/issues/558Broken links on Maven site2019-07-05T17:41:51ZSébastien Dinotsebastien.dinot@csgroup.euBroken links on Maven siteHere are two broken links in the documentation site generated by Maven:
* [licence.html](https://www.orekit.org/site-orekit-development/license.html)
* [team-list.html](https://www.orekit.org/site-orekit-development/team-list.html)
Lin...Here are two broken links in the documentation site generated by Maven:
* [licence.html](https://www.orekit.org/site-orekit-development/license.html)
* [team-list.html](https://www.orekit.org/site-orekit-development/team-list.html)
Links to the first page are available in the source files below:
* [src/site/site.xml](https://gitlab.orekit.org/orekit/orekit/blob/master/src/site/site.xml#L34)
* [src/site/markdown/index.md](https://gitlab.orekit.org/orekit/orekit/blob/master/src/site/markdown/index.md)
No link to the second link found in source files, but there are 675 occurrence of this link in the generated page [target/site/changes-report.html](https://www.orekit.org/site-orekit-development/changes-report.html).10.0https://gitlab.orekit.org/orekit/orekit/-/issues/564Visibility of AbstractGaussianContributionContext2019-06-25T19:49:29ZPetrus HyvönenVisibility of AbstractGaussianContributionContextHi,
In the AbstractGaussianContribution (and field version) there is a protected abstract getLLimits(SpacecraftState state, AbstractGaussianContributionContext context), where it seems like the AbstractGaussianContributionContext is not...Hi,
In the AbstractGaussianContribution (and field version) there is a protected abstract getLLimits(SpacecraftState state, AbstractGaussianContributionContext context), where it seems like the AbstractGaussianContributionContext is not specified as I understand it defaults to private, and thus cannot be accessed? Maybe this abstract class is not for general usage outside DSST, but then we should mark it as such?10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/565Static loading of GLONASS in LazyLeapHolder2019-06-25T19:49:51ZPetrus HyvönenStatic loading of GLONASS in LazyLeapHolderThe LazyLeapHolder has a static loading of UTC in the getGLONASS() mehtod of TimeScalesFactory.
```
private static class LazyLeapHolder {
/**
* Reference epoch for GLONASS four-year interval number: 1996-01-01T00:00:0...The LazyLeapHolder has a static loading of UTC in the getGLONASS() mehtod of TimeScalesFactory.
```
private static class LazyLeapHolder {
/**
* Reference epoch for GLONASS four-year interval number: 1996-01-01T00:00:00
* GLONASS time.
*/
public static final AbsoluteDate GLONASS_EPOCH = new AbsoluteDate(
DateComponents.GLONASS_EPOCH,
TimeComponents.H00,
TimeScalesFactory.getGLONASS());
}
```10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/566ITRFVersionLoader is private2019-07-05T17:41:51ZEvan WardITRFVersionLoader is privateIn 10.0-RC1 the class `ITRFVersionLoader` is private which prevents users from adding their own EOP loaders for EOP formats not supported by Orekit. I will make this class public so that users can add EOP loaders for custom formats.In 10.0-RC1 the class `ITRFVersionLoader` is private which prevents users from adding their own EOP loaders for EOP formats not supported by Orekit. I will make this class public so that users can add EOP loaders for custom formats.10.0Evan WardEvan Ward