#1676 import extra sdks automatically into ide - #2073
Conversation
- Load extra SDKs from ide-extra-tools.json and register supported ones in IntelliJ. - The IntelliJ merge template is expected from the settings repository.
…utomatically-into-IDE-' into feature/1676-Import-extra-SDKs-automatically-into-IDE-
…atically-into-IDE-
vivu001
added
enhancement
Coverage Report for CI Build 31395384239Coverage increased (+0.09%) to 73.033%Details
Uncovered ChangesNo uncovered changes found. Coverage Regressions48 previously-covered lines in 6 files lost coverage.
Coverage Stats
💛 - Coveralls |
…med attribute placeholders in jdk-extra-java.xml
hohwille
left a comment
hohwille
left a comment
There was a problem hiding this comment.
@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.
…-into-IDE- # Conflicts: # CHANGELOG.adoc
|
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. |
| @Override | ||
| public ToolInstallation install(ToolInstallRequest request) { | ||
|
|
||
| configureWorkspace(); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
- 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 duringconfigureWorkspace()we create theidea.propertiesin 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. - 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...
There was a problem hiding this comment.
Thanks for the review and for suggesting that we align once more before finalizing the implementation of this issue. Based on your feedback, I made a few changes to address your concerns. Hopefully, we'll be able to finalize this issue at the next daily.
- Generalized workspace configuration: a
runTool()override was added to theIdeToolCommandlet. It callsconfigureWorkspace()only when the IDE is launched. This allows Eclipse and VS Code to configure their workspace at launch without any IDE‑specific code.
I also removed theinstall()override fromIdeToolCommandletbecause it does not add behavior anymore. - Removed IDEA-specific workspace configuration: the IDEA-specific
configureWorkspace()was called fromIdeaBasedIdeToolCommandlet.runTool(), preventing workspace setup from being triggered on every plugin installation.
In addition, to ensure the update flow always performs synchronization: the loop that calls configureWorkspace() after extra‑tool installation was moved out of the if (extraTools != null) {} block in AbstractUpdateCommandlet. The method now runs on every ide update and synchronizeExtraToolInstallations() simply becomes a no‑op when there are no extra tools.
Summary of current behavior by IDE
| Feature | IntelliJ / IDEA | Eclipse | VS Code |
|---|---|---|---|
Workspace config on IDE launch (ide <ide>) |
✅ via IdeToolCommandlet.runTool() |
✅ via IdeToolCommandlet.runTool() |
✅ via IdeToolCommandlet.runTool() |
| Workspace config during plugin install | ✅ skipped (plugin install uses DEFAULT) |
✅ skipped | ✅ skipped |
| Extra-SDKs sync on IDE update | ✅ always invoked after extra-tools install | ✅ (same) | ✅ (same) |
| Extra-SDKs template registration | ✅ (e.g. Java → jdk.table.xml) |
❌ none registered yet | ❌ none registered yet |
There was a problem hiding this comment.
I was not so sure what for IntelliJ the cell ✅ skipped (plugin install uses DEFAULT) finally means and if maybe the plugins will be installed globally in home directory and then be missing when the IDE gets configured and started later.
I therefore cloned your feature-branch and installed a local release using our excellent ./build-local-dev.sh script.
Then I created a new test project:
$ ide create extra-sdks https://github.com/devonfw/ide-settings.git#feature/test-pr-2073
Then I did this:
$ ide install intellij
No CVEs found for version 2026.2.0.1 of tool intellij.
Resetting all installed plugins...
Start: Install plugin PlantUMLIntegration (1/1)
Successfully installed plugin: PlantUMLIntegration
Successfully ended step 'Install plugin PlantUMLIntegration (1/1)'.
Successfully installed intellij in version 2026.2.0.1 at D:\projects\extra-sdks\software\intellij
Successfully completed ide (install,intellij)
This revealed exactly the bug I proposed before:
$ ls -la plugins/intellij/
total 0
drwxr-xr-x 1 hohwille 1049089 0 Aug 10 16:36 .
drwxr-xr-x 1 hohwille 1049089 0 Aug 10 16:36 ..
When I now run Intellij the plugin PlantUMLIntegration is not preinstalled.
I conclude that we need to fix this properly and cannot include this into the current release.
There was a problem hiding this comment.
This can be fixed by running configureWorkspace in the postInstall() step of PluginBasedCommandlet.
Something like:
@Override
protected void postInstall(ToolInstallRequest request) {
super.postInstall(request);
Path pluginsInstallationPath = getPluginsInstallationPath();
if (!request.isAlreadyInstalled() || this.forcePluginReinstall.isTrue()) {
LOG.info("Resetting all installed plugins...");
deleteAllPlugins(pluginsInstallationPath);
}
this.context.getFileAccess().mkdirs(pluginsInstallationPath);
// the fix.
if (this instanceof IdeToolCommandlet) {
((IdeToolCommandlet) this).configureWorkspace();
}
installPlugins(request.getProcessContext());
}This way, workspace configuration is executed once per IDE during installation, before plugin installation starts — instead of being triggered for each individual plugin. This ensures the IDE configuration (e.g., idea.properties) is in place so plugins get installed to the correct location.
This should solve the problem.
…-into-IDE- # Conflicts: # CHANGELOG.adoc
hohwille
left a comment
hohwille
left a comment
There was a problem hiding this comment.
Sorry, forgot to submit the review
| this.repository = add(new RepositoryProperty("", false, IdeContext.FOLDER_REPOSITORY)); | ||
| } | ||
|
|
||
| @Override | ||
| public String getName() { | ||
|
|
||
| return "repository"; | ||
| return IdeContext.FOLDER_REPOSITORY; |
There was a problem hiding this comment.
Great that you did a global refactoring extracting this constant.
However the name of the repository commandlet is not exactly the same thing as the FOLDER_REPOSITORY so if we would change the value of that constant in the future, we do not also want to change the commandlet and property name here.
| if (processMode == ProcessMode.BACKGROUND) { | ||
| configureWorkspace(); | ||
| } | ||
| return super.runTool(pc, processMode, args); |
There was a problem hiding this comment.
You found a good solution for this. However, assuming ProcessMode.BACKGROUND could be a little fragile.
I am not expecting that we may install plugins in background in the future, but maybe we change this in IdeToolCommandlet:
public ProcessResult runTool(List<String> args) {
return runTool(ProcessMode.BACKGROUND, null, args);
}
We have issues like #218 and we might then want to use the new mode for all IDEs changing the above code.
So all I am suggesting here is to make this more robust:
| if (processMode == ProcessMode.BACKGROUND) { | |
| configureWorkspace(); | |
| } | |
| return super.runTool(pc, processMode, args); | |
| if ((processMode != null) && processMode.isBackground()) { | |
| configureWorkspace(); | |
| } | |
| return super.runTool(pc, processMode, args); |
| // Synchronize extra tools into all IDE workspaces (always run, even if extraTools is null — | ||
| // synchronizeExtraToolInstallations() handles the no-op case internally) | ||
| List<String> ides = IdeVariables.CREATE_START_SCRIPTS.get(this.context); | ||
| if (ides != null) { | ||
| for (String ideName : ides) { | ||
| ToolCommandlet ideCommandlet = commandletManager.getToolCommandlet(ideName); | ||
| if (ideCommandlet instanceof IdeToolCommandlet) { | ||
| ((IdeToolCommandlet) ideCommandlet).configureWorkspace(); | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
I am snot getting this.
The variable CREATE_START_SCRIPTS should only trigger what already AbstractUpdateCommandlet.createStartScripts() does.
It has nothing to do with configureWorkspace what will happen, when the end user runs the generated start script.
| // Synchronize extra tools into all IDE workspaces (always run, even if extraTools is null — | |
| // synchronizeExtraToolInstallations() handles the no-op case internally) | |
| List<String> ides = IdeVariables.CREATE_START_SCRIPTS.get(this.context); | |
| if (ides != null) { | |
| for (String ideName : ides) { | |
| ToolCommandlet ideCommandlet = commandletManager.getToolCommandlet(ideName); | |
| if (ideCommandlet instanceof IdeToolCommandlet) { | |
| ((IdeToolCommandlet) ideCommandlet).configureWorkspace(); | |
| } | |
| } | |
| } |
| @Override | ||
| public ToolInstallation install(ToolInstallRequest request) { | ||
|
|
||
| configureWorkspace(); |
There was a problem hiding this comment.
I was not so sure what for IntelliJ the cell ✅ skipped (plugin install uses DEFAULT) finally means and if maybe the plugins will be installed globally in home directory and then be missing when the IDE gets configured and started later.
I therefore cloned your feature-branch and installed a local release using our excellent ./build-local-dev.sh script.
Then I created a new test project:
$ ide create extra-sdks https://github.com/devonfw/ide-settings.git#feature/test-pr-2073
Then I did this:
$ ide install intellij
No CVEs found for version 2026.2.0.1 of tool intellij.
Resetting all installed plugins...
Start: Install plugin PlantUMLIntegration (1/1)
Successfully installed plugin: PlantUMLIntegration
Successfully ended step 'Install plugin PlantUMLIntegration (1/1)'.
Successfully installed intellij in version 2026.2.0.1 at D:\projects\extra-sdks\software\intellij
Successfully completed ide (install,intellij)
This revealed exactly the bug I proposed before:
$ ls -la plugins/intellij/
total 0
drwxr-xr-x 1 hohwille 1049089 0 Aug 10 16:36 .
drwxr-xr-x 1 hohwille 1049089 0 Aug 10 16:36 ..
When I now run Intellij the plugin PlantUMLIntegration is not preinstalled.
I conclude that we need to fix this properly and cannot include this into the current release.
|
This PR will be continued here: #2320 |
5 participants
This PR fixes #1676
Implemented changes:
1. Register the IntelliJ template
2. Read extra tool installations
$IDE_HOME/settings/ide-extra-tools.json.For example:
3. Keep SDKs synchronized
ide createoride updateand before the IDE starts.4. Validate configuration and handle errors
java.5. Added GraalVM reflection metadata to reflect-config.json
IntellijviaIdeToolCommandlet-based lookup.Testing instructions
1. Build the native executable
IDEasy/cli/target.2. Create a test project with custom settings
IDEasy/cli/target, create a new test project using the modified settings from my test branch foride-settings.3. Verify automatic SDK import in IntelliJ
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 updatebehavior4.1 Prepare test scenario
4.2 Run 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.xmlhas 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.
mvn clean testlocally all tests pass and build is successful#«issue-id»: «brief summary»(e.g.#921: fixed setup.bat). If no issue ID exists, title only.In Progressand assigned to you or there is no issue (might happen for very small PRs)with
internal