search

eclipse-oomph / oomph

Eclipse Public License 2.0
6 stars 11 forks source link

Applying a configuration with a project in a fresh environment requires a pre-installed JDK #112

Closed HannesWell closed 1 month ago

HannesWell commented 1 month ago

When applying an Oomph configuration, which contains an installation and workspace with product and project in a completely clean environment, one is asked to specify the path to a JDK and there is no way to omit specifying one.

This means that one needs to install a JDK manually before the application of the configuration can be completed. This is unfortunate since Oomph actually will install a JDK, usually of a matching or even higher version. On workaround might be to install just the product and to apply the configuration then later.

But ideally by default the installer would just use the JDK to be installed by Oomph. This could maybe be done by setting the future path of the to be installed JDK and ignoring that it doesn't exist yet. Of course if a user wants to this variable should still be overidable.

If you know a better strategy to solve this or have some pointers where to start, I can look into solving this.

grafik

merks commented 1 month ago

This Browse... button is now enabled also when used for the property field on the Variables page:

image

It's been enhanced to open a filtered view of the available adoptium downloads:

https://adoptium.net/temurin/releases/?os=windows&arch=x64&version=17

There is no general knowledge about a future location of a JRE/JDK. Which JDK is used to run the installation is generally unrelated to the JRE configured in the IDE and it can and is selected in different ways. If one chooses a JDK on the machine, then the dialog/selection will not be empty. If one chooses a JustJ JRE, we don't know the exact version and hence the location until looking in the p2 repository. Of course one could also just not have a JRE task at all and end up with an IDE where there is only a JRE corresponding to the one running the installation. Having a JRE that's specifically a Java 17 JRE because that's what's currently targeted seems like a good thing, even if the IDE itself is running with Java 21. I expect that folks who will be contributing to enhancing the Eclipse IDE's complex frameworks will have an easy time installing Java...