Favorite Java IDE

[salvatore-coppola]

Greetings to the Eclipse Kura community!

The Kura team is working on a complete overhaul of the tools and development environments involved in Kura development.

We would therefore like to hear from you what is your default/preferred IDE used in day-to-day development.

Thank you!

[mattdibi]

Others: anything but Eclipse IDE

[SteffenSenchyna]

@GregoryIvo, please release me from the eclipse prison.

[mattdibi]

Hello there @SteffenSenchyna, I apologise for the radio silence: we've been really busy with other projects emergencies and the new releases of Kura. Only last week I was able to resume the work on IntelliJ IDEA integration.

Unfortunately we've got bad news about it.

Both me and @pierantoniomerlino, after the initial experiments, were not able to set up the IDE in a way that allows us to run and debug unit tests. In my previous message I stated that it was working for me... but for whatever reason it was not reproducible nor stable (it stopped working almost immediately). Unfortunately the lack of unit test debugging/running is a showstopper for our adoption. I tried my best multiple times on multiple machines but I clearly lack the skillset to fix the issue and can't get out of this hole on my own.

I think there's something we're missing.

As a last resort/attempt I would like to ask you if you can describe in even more detail how do you setup IntelliJ idea for Kura development on a clean machine (or even a screen recording of the setup). Hopefully this would clean things up for us. Feel free to decline if you don't have the time obviously.

[SteffenSenchyna]

Hi @mattdibi no worries I will try and reproduce my steps from a clean setup and see if I can reproduce my previous success. Before I try this out I would just like to confirm which version of Java should be used 8 or 17?

[mattdibi]

Hi @SteffenSenchyna,

thanks 🙏 this is really appreciated. If you ever come to Italy we'll cover all your beer expenses 😄

which version of Java should be used 8 or 17?

17 since this is what we're moving to.

[SteffenSenchyna]

Hi @mattdibi just checking in to say I am still working on this, this time around InteliJ seems to be even less stable for loading the project dependencies properly, not sure what changed.

[mattdibi]

Hi @SteffenSenchyna, thanks for chiming in and taking the time to work on this. Timing is not an issue, don't worry.

[gnunzi]

Hallo, I am reposting here the picture of the heater example under vscode from a parallel discussion.

I realized that vscode probably works already for new kura modules out-of-the box. This should be easy if the module is packaged as "bundle" like the heater example. For other packagings it might be a bit trickier.

Is this of any value?
In case, we could extend the documentation to explain how to use vscode for new modules.

[mattdibi]

Hello there @gnunzi,

can you share what VSCode plugins did you use for this setup? As I already shared in the other discussion, we already experimented with VSCode here. Ultimately we abandoned the idea since, despite working quite well, it still required a functioning Eclipse IDE installation to work (Eclipse PDE support in VSCode requires .classpath and .project files which are only generated by Eclipse IDE).

[gnunzi]

Hi @mattdibi,
I am using the "standard" plugins. Down below is a screenshot from a codespace instance.

The Eclipse PDE is presumably needed by the "eclipse-plugin" modules. The "bundle" modules are handle by the maven-bundle-plugin (bnd tools) and need an explicit declaration of the dependecies in the pom (like the heater example) - no need for the Eclipse PDE.
This looks perfectly fine to me for the scenario of creating a new module, since you basically just need the kura.api bundle and the osgi annotations+interfaces bundles (like in the heater example). The bnd tools are to my knowledge also the easiest way to develop in OSGi (in particular the automatic generation of the manifest and of the metadata from annotations are a booster).

The only trick for a "new module scenario" is to open the module's directory only. Then you have a clean IDE with hints to your module only. The parent pom is resolved from the local m2 repo, no need to have it open in your IDE (of course you need to run mvn install on kura's pom first).

The handling of the versions in the dependencies needs some thinking. One could use open-ended release versions (maybe ok for a "new module scenario"). Or one can use the snapshot versions, but then they should be updated at each release.

You can see an example in https://github.com/gnunzi/kura-fork/blob/example-new-module/kura/example-new-module/pom.xml.

You can see it is reported as "bundle" module. Then it gets compiled, packaged and installed.

I find this approach particularly useful for new modules, since there is almost no learning curve to start writing a new component. I actually created an article last year already on a similar procedure, but for docker deployment: https://github.com/gnunzi/kura-components-with-annotations/blob/main/README.md (maybe outdated).

Here the plugins I used on a codespace for testing today:

[gnunzi]

Hi @mattdibi,

I realized that the same "trick" in vscode can be applied to exiting modules as well.
In this case one would better create a workspace file (not open directory), since it is possible there to declare mulitple modules to work on, like here below:

The packaging for exiting modules needs to be changed in this case to "jar" (only on those modules being currently worked on), because the exisitng manifest and osgi files are to be used (in "bundle" modules those files are auto-generated).

It works on my current setup. The existing manifest is in the jar together with the existing osgi files. It does not work for all modules yet, but it does work on single modules.

Of course, one could switch to "jar" for development and back to "eclipse-plugin" for pushing in order to keep the current pipeline working as before.

Below there is a screenshot. You can see the three modules recognized as Java and Maven projects. Code hints is working. Vscode fetches for the H2DbService class a binary file (lower part of the screen), presumably fetched from the local m2 repo. Of course, one could add the path to the the kura.api module in vscode, but this is not needed, since kura.api is only a dependency.

I can follow-up on this as soon as I cleaned-up my setting.

Nervetheless, for "new modules" the approach discussed previously (maven-bundle-plugin and autogenerated manifest) should be working already.