#1548: avoid Windows plugin locks during IDE updates

[cap-juan]

This PR fixes #1548

Implemented changes:

This PR changes plugin handling so that IDE updates on Windows no longer fail when the currently running IDE keeps files from an old plugin installation locked.

Previously, plugins were installed into one shared directory per IDE, for example:
plugins/intellij/

During an IntelliJ update, IDEasy reset this directory before installing plugins for the new IDE version. On Windows, this could fail when the currently running IntelliJ instance still had plugin files open, for example native files belonging to plugins such as GitHub Copilot.

Plugins are now stored per IDE version:

plugins/intellij/
├── 2026.1.4/
└── 2026.2/

This allows the new IDE version and its plugins to be installed independently from the plugin directory still used by the running old IDE.

Plugin directory handling

PluginBasedCommandlet now resolves the plugin installation path using the installed IDE version: plugins/<tool>/<version>

For example:

plugins/intellij/2026.2
plugins/pycharm/2026.2
plugins/android-studio/2024.1.1.1
plugins/eclipse/2024-09

Plugin marker files also contain the IDE version so plugin state is tracked independently for each installed IDE version. After plugins for the new IDE version have been installed, IDEasy tries to remove obsolete version directories (this cleanup is best-effort only).

If Windows prevents deletion because the old IDE still holds files open, IDEasy logs a warning such as:

Could not delete obsolete plugin directory ...\plugins\intellij\2026.1.4.
It may still be in use and will be cleaned up later.

The IDE update itself continues successfully. Once the old IDE is closed, a later install/update can remove the obsolete plugin directory.

JetBrains IDE plugin loading:

IntelliJ-based IDEs are configured to use the version-specific plugin path through:
-Didea.plugins.path=<IDE_HOME>/plugins/<tool>/<version>

The generated VM options therefore point each IDE version to its corresponding plugin directory. Example:
-Didea.plugins.path=C:\Users\...\IDEasy\plugins\intellij\2026.2

This applies to IntelliJ IDEA, PyCharm and Android Studio.

JetBrains Marketplace plugin installation:

Marketplace plugins are now downloaded directly instead of invoking the IDE's installPlugins command.

This is important because invoking IntelliJ while another IntelliJ instance is already running can fail with the single-instance restriction and therefore still prevent plugin installation during an IDE update.

Plugin archives are installed according to their archive type:

ZIP plugins are extracted directly into the version-specific plugin directory so their own directory structure is preserved. For example a Marketplace archive containing:

plantuml4idea/
└── lib/
    └── ...

becomes:

plugins/intellij/2026.2/
└── plantuml4idea/
    └── lib/
        └── ...

JAR plugins are extracted into a directory named after the plugin ID. This distinction is necessary because standalone plugin JARs do not necessarily contain their own surrounding plugin directory. Custom plugin repository URLs continue to use the existing IDE command-based installation mechanism.

Other IDEs:

VS Code now also uses the version-specific plugin directory through its --extensions-dir argument.

Eclipse configuration paths are based on the version-specific plugin installation directory, for example:
plugins/eclipse/2024-09/configuration

Tests were updated accordingly.

---

Testing instructions

Please add concise, understandable instructions on how a reviewer can test/verify the functionality of your contribution here:

The issue was reproduced using IntelliJ IDEA on Windows.

1. Configure an older IntelliJ version, for example: INTELLIJ_VERSION=2026.1.4

2. Install IntelliJ: ide install intellij

3. Verify that the configured plugin is installed under the version-specific directory: ls -la "$IDE_HOME/plugins/intellij"

Expected: 2026.1.4

4. Start IntelliJ: ide intellij

5. Keep the old IntelliJ instance running.

6. Change the configured IntelliJ version to a newer supported version, for example: INTELLIJ_VERSION=2026.2

7. While the old IntelliJ instance is still running, execute: ide update

8. Verify that:

IntelliJ 2026.2 is installed successfully.
Plugins for 2026.2 are installed into: plugins/intellij/2026.2
the running IntelliJ instance may keep the old plugin directory locked;
IDEasy only logs a warning when deletion of the old directory fails;
the overall ide update still completes successfully.

Example warning:

Could not delete obsolete plugin directory ...\plugins\intellij\2026.1.4.
It may still be in use and will be cleaned up later.

9. Close the old IntelliJ instance and start the new one: ide intellij

10. Verify:

Help -> About shows the new IntelliJ version.
the configured plugin is available under Settings -> Plugins -> Installed.
the generated VM options contain the new version-specific plugin path.

Example:
-Didea.plugins.path=...\plugins\intellij\2026.2

11. Close IntelliJ and run another update: ide update

12. Verify that the obsolete plugin directory can now be removed and only the current plugin directory remains: ls -la "$IDE_HOME/plugins/intellij"

Expected: 2026.2

---

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 and not feature/921 fixed setup.bat). If no issue ID exists, title only.
• PR top-level comment summaries 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 labelled
  with internal
• You have not changed any dependency in pom.xml files or otherwise if runtime dependencies changed, you have updated our LICENSE.asciidoc
• You have formulated clear instructions on how to test your contribution under "Testing instructions"

Checklist for tool commandlets

Have you added a new «tool» as commandlet? There are the following additional checks:

• The tool can be installed automatically (during setup via settings) or via the commandlet call
• The tool is isolated in its IDEasy project, see Sandbox Principle
• The new tool is added to the table of tools in LICENSE.asciidoc
• The new commandlet is a command-wrapper for «tool»
• Proper help texts for all supported languages are added here
• The new commandlet installs potential dependencies automatically
• The variables «TOOL»_VERSION and «TOOL»_EDITION are honored by your commandlet
• The new commandlet is tested on all platforms it is available for or tested on all platforms that are in scope of the linked issue

[coveralls]

Coverage Report for CI Build 32729199500

Coverage increased (+0.04%) to 73.511%

Details

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

Uncovered Changes

No uncovered changes found.

Coverage Regressions

55 previously-covered lines in 6 files lost coverage.

File	Lines Losing Coverage	Coverage
com/devonfw/tools/ide/tool/ide/IdeaPluginDownloader.java	19	68.75%
com/devonfw/tools/ide/tool/plugin/PluginBasedCommandlet.java	18	87.27%
com/devonfw/tools/ide/tool/ide/IdeaBasedIdeToolCommandlet.java	12	81.94%
com/devonfw/tools/ide/io/FileAccess.java	4	86.96%
com/devonfw/tools/ide/io/FileAccessImpl.java	1	69.7%
com/devonfw/tools/ide/tool/ide/IdeToolCommandlet.java	1	87.42%

---

Coverage Stats

Relevant Lines:	18111
Covered Lines:	13919
Line Coverage:	76.85%
Relevant Branches:	8043
Covered Branches:	5307
Branch Coverage:	65.98%
Branches in Coverage %:	Yes
Coverage Strength:	3.27 hits per line

---

💛 - Coveralls