Configuring IDE w/Latest Version

I’m trying to load up the latest version of Orekit into my prefered IDE (IntelliJ) and then Eclipse (if I have to) and am failing on both accounts. These both seem to be around the DefaultDataContextPlugin object. In both cases when trying to run the unit tests it won’t compile because the DefaultDataContectPulugin object isn’t found. Under Eclipse it shows up as source code error. Under IntelliJ it shows up as a ServiceConfigurationError. In IntelliJ I was getting compiling errors until I added the tools.jar path manually to my settings but once removed it seems to have stuck.

Is there a manual on configuring IDEs or if not can anyone shed some light on how they setup their development environment for the new build with this plugin architecture? I’m having no problem building from the command line thankfully but we have to be able to quickly get people up and running in IDEs as well.

Hi Hank,

We had some discussions with Evan about this issue. The discussion start from the post at the following link. In summary, Evan proposes to think about multi-modules project for Orekit.

Bryan

1 Like

Hi Hank,

Bryan and I are using Eclipse and we identified the issue a few weeks ago in the thread Bryan mentioned.
Eclipse Maven plugin is not following the Maven build properly and it leads to a compilation error; and an error in the tests.
For now with Eclipse what I’m doing is a “clean install” with skipping the tests.
If I want to run the tests I do it manually (right click on src/test/java package -> run with JUnit).
Or, as you said, you can run a Maven command line, it works!
I don’t think there will be a solution for Eclipse until Maven plugin is fixed or we move to multi-modules (next major version) as Bryan also mentioned.
I think @luc opened an issue on the Maven plugin forge, I ran into it while I was looking for clues but I haven’t tried to find it again. I can do some digging if you’re interested.

As for IntelliJ I think @evan.ward (and maybe @yannick too ?) managed to make it work on their own machines, maybe they would be able to help you set it up.

Cheers,
Maxime

1 Like

I only had Eclipse on long enough to test but I’m continuing to debug with IntelliJ. Since the problem is in the build process the only thing I’ve been able to come up with is manually building the tests from the command line and disabling building of tests in the run configuration. You never realize how much incremental compilation speeds things up until you have to rebuild stuff like this over and over. I’m glad there is an issue for this. It seems like setting up standard IDEs should be a streamlined thing. Thankfully this is just a problem for Orekit developers not users.

Before I jumped to just disabling building through the IDE I tried adding the tools.jar to the classpath in the javac configuration for IntelliJ and it did not help with avoiding the not being able to find all the com.sun.source... classes.

Short term fix is to do the build once with maven (mvn verify) then you can run the tests in IntelliJ, just don’t rebuild the whole thing. IntelliJ will just recompile the files you changed. You may have to exclude the plugin package from compilation.

Hi @hankgrabowski,

I use IntelliJ both on my work computer and private computer. It was some time ago, but at work I am fairly sure that adding tools.jar was enough to solve my build issues. At home (using OpenJDK 13) I struggled more. I had to resort to the trick mentionned by @evan.ward.

I agree that this is a bit problematic. It could potentially scare off new developers.

I’m still unsuccessful at getting this working correctly. Part of the problem I’ve had is consistently finding tools.jar. Now I know why. They have removed tools.jar and rt.jar from the distribution as part of project Jigsaw in JDK 9. Do we have to look to look at refactoring how we are doing this to accommodate the fact that JDK 8 was the last JDK to have this construct?

https://openjdk.java.net/jeps/220

It seems the replacement for tools.jar is a module named java.compiler. I had been trying to stay with Java 8 because it is stable and the newer versions forgot the the value of backwards compatibility for a platform. I guess I’ll have to learn some about java modules. Perhaps we can make this change in the next major release where we are already planning to put the compiler plugin in a separate maven module.

It’s really only a problem for people developing on Orekit not users of Orekit so it’s not a huge huge problem right now for the community at large. The bigger problem will be when JDK 8 sunsets in a year or so. We’ll probably have to bump minimum versions by then if it can’t down-compile to JDK 8. In the mean time I’ll setup a new VM with JDK 8 on it and see if the suggestions here work for me under Linux (I’m assuming they will).

OpenJDK 8 is supported through May 2026.[1] But I expect others will want to upgrade sooner than that.

[1] https://access.redhat.com/articles/1299013

Ah yeah active support ends in 2022 but security patches are out to 2026. So we don’t really hit the “must abandon for security reasons” wall until 2026.

Personally, yes I’m desperate to not use JDK 8 :). I’d prefer to code in Kotlin over Java period but at least with Java 11 and 13 I get some of the niceties of Kotlin when on the Java side.

I wish the using JDK 8 fixed this for IntelliJ but it does not. I still can’t get it to build within the tool or incrementally run the tests when following the steps described here. I’ll develop in a side project and port it in afterward for the time being.

Would it break backwards compatibility to put the compiler plugin in a separate Maven module ?

Short answer is yes because it requires users to add a new jar to the classpath if they use it. But if users add the new maven dependency then it should function as it did before.

Ok I see, thanks @evan.ward.