Orekit 10.0 has been released 7 month ago (27/06/2019) and current developments of the new version are more or less finished. So it’s time to think about Orekit 10.1 !
Here is a list of the main changes already completed:
Combination of GNSS measurements.
Wind-up effect on GNSS measurements.
Support for Hatanaka compact RINEX format.
Laplace initial orbit determination method.
A new Field Of View package that includes circular, elliptical, dihedral and polygonal field of views.
Comparison methods in AbsoluteDate class.
Moved Orekit’s tutorials to a separate sister project.
NeQuick ionospheric model.
Improvement of the contributing guide.
Possibility to use multiplexed measurement.
IRNSS and SBAS analytical orbit propagators.
Possibility to write covariance matrices in OEM writers.
#607 (@evan.ward) I think this one is completed, isn’t it ?
Is there other developments that shall be performed before releasing Orekit 10.1 ? I think that the previous enumerated points are sufficient to make a great 10.1 version of Orekit !
I started a “cleanup” branch in order to fix the different warnings in the code (SpotBug, JavaDoc, …).
When they will be fixed, we will be able to start the release process.
I saw on Jenkins Coverage report that quality gates are not reached for code coverage. Indeed, coverage report show that there are 2 classes that are not covered by tests. The classes are DefaultDataContextPlugin and DefaultDataContextPlugin.AnnotationTreeScanner.
Do you think it is possible to add unit tests for these classes ?
Thank you in advance,
Now I have a compilation problem (I’m using Eclipse IDE) in the DefaultDataContextPluginTest class:
Description Resource Path Location Type
DefaultDataContextPlugin cannot be resolved to a variable DefaultDataContextPluginTest.java /orekit/src/test/java/org/orekit/compiler/plugin line 72 Java Problem
I think this problem occurs because the compiler package (folder src/main/java/) is excluded in the pom file.
There is another problem in the DataProvider class (see Jenkins output ). I think the problem is generated because the method feed (with 3 arguments) just calls the method feed (with 2 arguments). However, the method with 2 arguments has a @DefaultDataContext annotation. So, I think we have to add a @DefaultDataContext annotation to the default implementation of the feed method (with 3 arguments).
I prefer asking you before because I’m not familiar with this new feature
Yes, but it gets compiled during the process-resources phase, which is before the rest of the source is compiled. I’m not familiar with Eclipse, maybe Eclipse isn’t importing the Maven build process correctly? I use IDEA and it sometimes has a similar issue. I run mvn test-compile and after that IDEA works fine. So my processes is to use Maven to compile everything once, then the IDE will only recompile the files I changed.
A “cleaner” way to structure the build would be to use separate modules so that tools.jar could be listed in the dependencies section.
Yes that is a small issue, but I haven’t found a good solution. In short, it is probably best to just ignore the warning in this case.
I needed a way to add a parameter to a method in an interface in a backward compatible way so I used a default implementation. Maintaining backward compatibility required the default implementation to use the default data context since that is all there was in Orekit 10.0. All implementations of DataProvider in Orekit override the default implementation so as to not use the default data context. The only way the default implementation would be invoked is if a user has a custom implementation of DataProvider that has not been updated for Orekit 10.1. Hopefully marking feed with two arguments as @Deprecated will encourage users to use the thee argument method.
If feed with three arguments is annotated then DataProvidersManager and all of the LazyLoaded* classes would also need to be annotated. To me this would make the annotation less useful since there would be many false positives.
Assuming that most users of Orekit do not use custom DataProviders (or if they do they would update so as to not use the deprecated 2 argument feed) I decided not to annotate the method.
Another option would be to remove the @DefaultDataContext annotation from the DataProvider interface. That would be fine since nothing in the interface actually calls the default data context. The downside is that implementing feed(Pattern, DataLoader) requires use of the default data context and that calling that method would never be never be highlighted by the compiler plugin even if the implementation adds the @DefaultDataContext annotation. Since I wanted to check that no other classes in Orekit calls feed with two arguments I added the annotation to it.
In the end the compiler plugin should be used with ExceptionalDataContext and the latter will certainly catch this case.
Ok I agree with ignoring the warning. We will be more free at release 11.0 to fix this warning.
I think we are now able to start the release process. Javadoc, Spotbug and Java warnings are fixed. It can be interesting to add also the fix of the issue #639. Once the issue will be fixed, we will start with @MaximeJ the release process.
I’ve tried it in Eclipse and it doesn’t work. I still have the issue an a test error in DefaultDataContextPluginTest.java.
I think at some point we’ll have to add this tools submodule to Orekit.
Nevertheless, the error is not blocking and Bryan and I would like to release 10.1 soon.
I have no idea how long it would take to make this change and check that everything works fine. Do you have any idea about this @evan.ward ?
In my opinion, unless it can be done very quickly, I think this change can wait for 10.2. And we’ll need to discuss it further again with other developers.
If it is just three modules (orekit, annotation, compiler plugin) then my guess is that it would take about 4 hours, mostly for testing that the reports and site are still assembled correctly. If we release 10.1 as it is now then we should wait until 11.0 to create separate modules as it would introduce backward incompatibilities. I think it is fine to wait until 11.0. There was also some talk of creating more modules, which would be a larger project.
