#1676 import extra sdks automatically into ide

[vivu001]

This PR fixes #1676

Implemented changes:

1. Register the IntelliJ template

• Add the IntelliJ template for extra JDKs installations.
• Keep the approach reusable for other IDEs, such as Eclipse and VS Code.

2. Read extra tool installations

• Read extra tool installations from $IDE_HOME/settings/ide-extra-tools.json.
  For example:

{
  "java": {
    "client": {
      "version": "11.0.31_11",
	   "edition": "azul"
    },
    "process-engine": {
      "version": "21.*"
    }
  },
  "mvn": {
    "m4": {
      "version": "4.0.0-rc-5"
    }
  }
}

• Process each configured extra SDKs installation.

3. Keep SDKs synchronized

• Synchronize extra SDKs during ide create or ide update and before the IDE starts.
• Configure the workspace only after tools are installed.
• Use merge logic to update SDKs without duplicates (Related PR devonfw/IDEasy#1676: import extra sdks automatically into ide (new) ide-settings#91).

4. Validate configuration and handle errors

• Reject an extra-installation name that equals its tool name; for example, an extra JDKs installation must not be named java.
• Skip missing or invalid SDK installations and write a warning to the log.

5. Added GraalVM reflection metadata to reflect-config.json

• The new entries enable native-image to instantiate Intellij via IdeToolCommandlet-based lookup.

---

Testing instructions

1. Build the native executable

• Run the following script to build the native image: ./build-local-dev.sh.
• After the build completes, navigate to: IDEasy/cli/target.

2. Create a test project with custom settings

• From IDEasy/cli/target, create a new test project using the modified settings from my test branch for ide-settings.

ideasy.exe create <test-import-sdks> https://github.com/vivu001/ide-settings.git#feature/1676-Test-import-extra-SDKs-automatically-into-IDE

3. Verify automatic SDK import in IntelliJ

• Open a new terminal and initialize the workspace:

icd -p <test-import-sdks> -w

• Launch IntelliJ

ide intellij

• Expected result:
  All additional SDKs should be automatically imported into IntelliJ.
  This step validates that workspace configuration and IDE settings are correctly applied (as IDEasy manages IDE configuration via workspace templates).

4. Validate ide update behavior

4.1 Prepare test scenario

• Manually remove all extra JDKs from IntelliJ.
• Additionally, delete jdks from the filesystem:

$IDE_HOME/software/java 
$IDE_ROOT/_ide/software/default/java

4.2 Run update

ide update

4.3 Verify result

All previously removed SDKs are re-downloaded and reinstalled.
IntelliJ configuration is updated accordingly, as shown at the end of step 3.
The file $IDE_HOME/workspaces/main/.intellij/config/options/jdk.table.xml has been updated with the extra SDK entries.

Checklist for this PR

Make sure everything is checked before merging this PR. For further info please also see
our DoD.

• When running mvn clean test locally all tests pass and build is successful
• PR title is of the form #«issue-id»: «brief summary» (e.g. #921: fixed setup.bat). If no issue ID exists, title only.
• PR top-level comment summarizes what has been done and contains link to addressed issue(s)
• PR and issue(s) have suitable labels
• Issue is set to In Progress and assigned to you or there is no issue (might happen for very small PRs)
• You followed all coding conventions
• You have added the issue implemented by your PR in CHANGELOG.adoc unless issue is labeled
  with internal
• You have formulated clear instructions on how to test your contribution under "Testing instructions"

[coveralls]

Coverage Report for CI Build 30243693167

Coverage increased (+0.1%) to 72.69%

Details

• Coverage increased (+0.1%) from the base build.
• Patch coverage: No coverable lines changed in this PR.
• 51 coverage regressions across 7 files.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

51 previously-covered lines in 7 files lost coverage.

File	Lines Losing Coverage	Coverage
com/devonfw/tools/ide/commandlet/AbstractUpdateCommandlet.java	20	82.62%
com/devonfw/tools/ide/context/IdeContext.java	13	78.57%
com/devonfw/tools/ide/tool/ide/IdeaBasedIdeToolCommandlet.java	6	81.48%
com/devonfw/tools/ide/tool/ide/IdeToolCommandlet.java	6	90.55%
com/devonfw/tools/ide/tool/intellij/Intellij.java	4	89.41%
com/devonfw/tools/ide/tool/extra/ExtraTools.java	1	90.48%
com/devonfw/tools/ide/version/VersionSegment.java	1	91.34%

---

Coverage Stats

Relevant Lines:	17022
Covered Lines:	12899
Line Coverage:	75.78%
Relevant Branches:	7614
Covered Branches:	5009
Branch Coverage:	65.79%
Branches in Coverage %:	Yes
Coverage Strength:	3.21 hits per line

---

💛 - Coveralls

[hohwille]

@vivu001 thanks for your PR and sorry to interrupt before team review.
I had a look into your diff and found some misunderstandings and before moving any further, I wanted to guide the way to the proper solution.
You did a lot perfectly correct, but there are some misunderstandings between #1166 and #1676 that seemed not clear.
Also preparing this implementation for VSCode, Eclipse and other potential IDEs or even future SDKs I suggest some more generic approach and according refactoring.
Please have a look and see if you can follow my idea and suggestions.
If there are any questions do not hesitate to reach out.

[JoelAdbu]

I went through the testing instructions and was able to reproduce the expected behavior successfully. The extra SDKs were imported correctly, and ide update reinstalled and synchronized the SDKs as expected.
Apart from my comment regarding the exception handling, everything looks good to me.

[hohwille]

Ah great finding. So the big picture gets clearer.
But as I already wrote maybe this was done on purpose.
Can you test that without this still the plugins get installed into the correct plugins folder inside the IDEasy project and are found as installed when I launch ide intellij?
If that is the case, then this should solve the problem and we simply do not need to configure the workspace at all during installation and you can also remove the extra loop in AbstractUpdateCommandlet.

[vivu001]

I tested it: without configureWorkspace() in IdeToolCommandlet.install() the extra SDK installation is still unaffected. The extra SDKs are still installed by the create/update flow and the workspace synchronization is only needed later when ide intellij imports them.

In the AbstractUpdateCommandlet, removing the extra loop shows that extra SDKs still work when launching ide intellij, but the plugins are NOT installed into $IDE_HOME/plugins/intellij. So this workspace sync is still needed for plugin provisioning, even though the SDK part can already be handled at IDE launch.

[hohwille]

What is the current state and how can we finally resolve this.
IMHO this change is logically correct and also if noting is left in this method you can even remove the method override since it is pointless now.

However, as you also found out and confirmed the plugin installation requires somehow the workspace configuration to be triggered.
Reading your PR diff again, I now found that you are triggering this in IdeaBasedToolCommandlet when a plugin is to be installed.
However, then we are still not done:

1. How about other IDEs like VSCode or Eclipse - can we install plugins there without configureWorkspace() being invoked. Or is this only an IDEA/JetBrains specific thing not needed for other IDEs (because during configureWorkspace() we create the idea.properties in the workspace what makes this different from non-IDEA based IDEs)? IMHO for Eclipse and VSCode we will now never configure the workspace any more when we change your PR as is so it would be broken.
2. Performance impact: If we install 20 plugins, we will now configure the workspace 20 times. This seems to be a waste and in that case the old approach to trigger it once during the installation still seems more reasonable unless we somehow can remember that we already configured the workspace and do not rerun it for every plugin. Besides if there is an error or warning for a workspace template the user will be annoyed if he gets the same message 20 times so it is not only about performance.

I really like to merge this PR finally but IMHO this is still not 100% cleared to the end.
Maybe we have to clarify this at the end of the next daily since review ping-pong seems to take way too long...