+1 for the release!
I have checked signatures, content, tag and rebuilt/tested from the tag.
I only have one remark. In the maven artifacts, the orekit-10.0.source-jar and its signatures files could have been removed before closing the staging repository, so only orekit-10.0-source-jar and its signatures files (the difference is a dot instead of a dash in the name after the version number. The spurious file is created due to the configuration of a maven plugin, I was never able to prevent its creation and generally have to remove it manually. There is no harm in having this additional artifact, so don’t need to run a new release candidate.
Working on the python wrapping I ran into some issues with visibility. 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?
Hi again,
There seems to be a static variable definition in LazyLeapHolder that requires that the orekit-data is setup at initialization (TimeScalesFactory.getGLONASS()) as it is depending on getUTC()
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());
}
This gives problems in the python wrapping as the environment is not yet set up when the wrapping is performed.
We had some similar issue before, on getUTC() for the 9.3 release in GlobalPressureTemperature2Model
If a release candidate 2 is performed, perhaps you could also upload the orekit-10.0-src.zip archive and its signature files alongside with the generate site to the staging directory so we can review it is in sync with the git tag. This file is slightly different from the maven artifact orekit-10.0-sources.jar. It is more complete and contains all build and configuration files, whereas the maven artifact only contains sources for the sake of debugging within an IDE. The src.zip archive is generated when running mvn assembly:single.
Thanks everyone for all the testing. I will be creating a new release candidate to address all the issues mentioned here and #566. If you haven’t had a chance to test it yet please post any bugs/issues you find here so I can include them in RC2.
We noticed that the class diagrams generated in the site are very tall. This is a known problem due to a bug in graphviz, which is called by plantuml to render the graphs. This has been identified more than 3 years ago (see https://forum.plantuml.net/?qa=4531/possible-bug-with-relation-in-rectangle-screenshot and the plantuml developer did notify the graphviz project about the issue, but up to now it has not been fixed.
The solution is to downgrade graphviz to version 2.38. On my Debian computer, I use 2.38.0-19+b1 and put it on hold so it is never upgraded automatically.
Just one very minor remark, the FAQ page of the maven site would need a small update at § “What are Orekit dependencies?” in order to update dependencies to Hipparchus 1.4 and 1.5 for Orekit 9.3 and 10.0.
The name “G2” is given for both R02 and R03. There is a public method getName() to access the name of the frequency. So the user can be impacted by this issue.