#1676: import extra sdks automatically into ide

[JoelAdbu]

This PR fixes #1676

• this pr is a follow-up to PR: #1676 import extra sdks automatically into ide  #2073

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 31963985344

Warning

No base build found for commit 31dabbf on main.
Coverage changes can't be calculated without a base build.
If a base build is processing, this comment will update automatically when it completes.

Coverage: 72.993%

Details

• Patch coverage: No coverable lines changed in this PR.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

Requires a base build to compare against. How to fix this →

---

Coverage Stats

Relevant Lines:	17608
Covered Lines:	13403
Line Coverage:	76.12%
Relevant Branches:	7785
Covered Branches:	5132
Branch Coverage:	65.92%
Branches in Coverage %:	Yes
Coverage Strength:	3.24 hits per line

---

💛 - Coveralls

[JoelAdbu]

I suggest this solution for your comment @hohwille: #2073 (comment)

[hohwille]

This will still not fix the bug:
Assume you create a new project and have intellij in IDE_TOOLS variable then intellij will still be installed with its plugins before the workspace is configured.
Also users can manually add intellij as I showed in my testing instructions how I reproduced this bug.
Then also this will not fix the problem.

A real fix would be to ensure that we create idea.properties before we install the plugins. Currently this only happens inside configureWorkspace() and that only happens when the IDE is launched.
That causes the bug:

1. install will install IDE with the plugins but due to missing idea.properties in the wrong location
2. launching IDE configures the workspace and relocates the plugins directory via idea.properties and then finds no plugins.

I hope now everything is clear.

[JoelAdbu]

I think this fix addresses a different issue.

The change in AbstractUpdateCommandlet is intended for the update scenario, e.g. when IntelliJ is already running and an update synchronizes extra SDKs into an existing workspace. In this case, users do not need to restart IntelliJ via ide intellij, but can simply restart it from within IntelliJ.

The issue you describe regarding plugin installation during the initial IDE installation should rather be addressed by the change discussed here: #2320 (comment)

My intention there was to ensure that configureWorkspace() is executed before plugins are installed, so that idea.properties already exists and points to the correct plugin directory.
 
That said, I totally agree with your OOP concern. Having PluginBasedCommandlet know about IdeToolCommandlet via instanceof is not a clean design, and your suggested postInstall() approach would be preferable.

[hohwille]

I would still question this added loop.
The workspace configuration will be updated whenever we launch Intellij for the next time.
What will actually happen, if both the end-user changes preferences and therefore IntelliJ overwrites some workspace config file while also the end-user launched ide update in some terminal?

However, I now understand your change with postInstall() that will also trigger the workspace config update.
This is indeed a fix for what I was requesting for.

In the end, I want to summarise our main problems we were facing:

1. In order to install plugins, we already need to have idea.properties populated for the workspace as otherwise the plugins are installed into the wrong location and do not apply when Intellij is launched.
2. If we configure the workspace during the tool installation then on use-cases like ide create the workspace config can be wrong because the referenced extra tools may not yet installed. For that reason we actually wanted that the workspace configuration does not get triggered during the installation but only when the IDE gets started. This again conflicted with 1.

IMHO the cleanest approach would be to somehow extract the creation of the Jetbrains specific IDEA properties file always (when installed and when launched) but do the rest of the workspace configuration only when the IDE gets launched. This is also specific only for IdeaBasedIdeToolCommandlet and its subclasses, so all tweaks we consider here do not affect e.g. Eclipse or VSCode (where it already works if we do not configure the workspace during installation).
The thing is that our workspace configuration is solved fully generic and we decided to reuse that generic process also for these properties. Example:
https://github.com/devonfw/ide-settings/blob/main/intellij/workspace/update/idea.properties

I would now like question this decision: Did we take a bad choice that we should change?
In IdeaBasedIdeToolCommandlet we already have custom logic for composing an VM_OPTIONs variable depending on the IDE type (intellij, android-studio, pycharm).
In the same way, we could create this properties file here explicitly and remove it from the settings.
Using the generic approach with the idea.properties as workspace template also gives some flexibility.
However, in this specific case I would rather think that this is more an implementation detail of IDEasy than something that the end-user should have arbitrary control over because in most cases, he will only break the proper IDE integration. We would then also have to clarify if we somehow want to ignore this specific properties template in the future when IDEasy is changed accordingly and only render a warning.

So to come to an end we should:

1. agree if we want to keep or remove this extra loop on workspace configuration during ide update / ide create. I currently would vote for removing it but am still open to keep it if it holds my challenging questions.
2. create a new issue of my current concern and finally decide what we want to do about this but get this PR finally done and merged and consider this latest discussion as a new feature to be addressed in a separate PR.

[JoelAdbu]

1. I removed the additional workspace configuration loop again.

IMHO, it is acceptable that after an ide update which installs or updates extra SDKs, the user may need to close IntelliJ and start it again via ide intellij in order to pick up the updated configuration.
Given the concerns raised about running workspace configuration during ide update and ide create, I think removing the additional loop is the safer approach for now.

2. I have create a separate research issue: Reconsider treating idea.properties as a user-configurable workspace template #2336 to trach the architectural discussion around idea.properties

The issue covers the questions raised in this discussion, especially whether idea.properties should remain part of the settings repository and generic workspace configuration process, or whether it should instead become an implementation detail of IdeaBasedIdeToolCommandlet.

Since there is no clear decision yet on the preferred long-term approach, I created it as a research task so the topic can be evaluated independently from this PR.