#2045: Add tool slection and version or edition configuration via gui

[KarimALotfy]

This PR fixes #2045

Implemented changes:

A Tools Configuration tab that lets users manage which tools are active in their IDEasy workspace and what version/edition each one uses, all persisted to ide.properties in the project settings layer.

How it works

Opening the tab — After selecting a Project and workspace, the "Tool Config" tab is enabled, clicking it triggers a background load of listToolConfigurations, which walks the CommandletManager and reads each tool's current version and edition from the environment variables. Then the tab is populated with the list of tools

The tree view — tools are grouped by type (IDE, Global, Local, NPM, PIP, Other) and sorted alphabetically within each group. Each row has an enable checkbox, the tool name, an edition combo (if the tool has more than one configurable edition, and a version combo.

Editions — after the tab opens, a single background thread walks all tools and calls loadEditionsForTool (a repository directory scan) for each, then triggers a single toolsTree.refresh() when done. The edition combo is hidden for tools with ≤1 edition. If exactly one edition
exists and none is configured, it is auto-selected.

Versions — the version combo lazy-loads on first open to avoid fetching all tools' version lists upfront. When the user changes the edition, the version list refreshes automatically in a background thread.

Because JavaFX doesn't repaint an already-open popup after its items change, the combo is hidden and reshown to force the updated list to appear.

Validation — version input is validated on focus-lost. A free-text entry that isn't in the loaded version list gets a red border and a ✗ error icon. Blank input is normalised to * (meaning "latest"). The Save and Preview buttons are disabled until all errors are resolved.

Saving — applyAndSave writes the enabled-tools list and per-tool _VERSION / _EDITION variables into the settings environment-variables layer and calls save(). Blank version strings are normalised to null (removes the variable). The _EDITION variable is only written/cleared for
tools where supportsEdition=true.

Preview — opens a read-only TextArea showing the exact ide.properties content that would result from the current state. Includes a Save button to apply directly from the preview.

---

Testing instructions

ToolSettingsServiceTest` covers all public methods:

• toToolConfiguration — name mapping, enabled/disabled, case-insensitive
  match, null enabled-tools list
• loadEditionsForTool — happy path, unknown tool, repository exception
• reloadVersionsForSelectedEdition — happy path, null/blank edition,
  unknown tool, repository exception
• buildPreviewSettingsContent — version/edition present, omitted when
  null/blank, edition suppressed when supportsEdition=false, multiple
  tools, no enabled tools
• applyAndSave — version and edition written, disabled tool clears
  existing entries, blank version clears existing entry, edition suppressed
  when supportsEdition=false, IDE_TOOLS list updated, backup created,
  no backup when file absent

Test plan

Unit tests

• Run ToolSettingsServiceTest — all 31 tests green

Opening the dialog

• Select a project and workspace on the main screen
• Click Tools Config — - New Tab opens with tools already grouped and visible; no blank flash
• After ~1–2 s, edition combos populate for tools that support them (e.g. IntelliJ)

Enabling / disabling tools

• Uncheck a tool — row dims and version/edition combos disable
• Re-check it — row becomes active again
• Disabled tools must not appear in the IDE_TOOLS line after saving

Edition combo

• For a tool with multiple editions (e.g. IntelliJ): combo is visible and
  populated after the background scan
• For a tool with one edition: combo is hidden; edition is auto-selected
• For a tool with no editions (e.g. mvn): no edition combo shown
• Changing the edition triggers a version list refresh in the background

Version combo

• Click the version dropdown before it has loaded — a short delay, then
  the popup reopens automatically with the version list
• After an edition change, the version list updates to match

Version validation

• Type a nonsense string into a version field, then click away —
  red border and ✗ icon appear; Save and Preview are disabled
• Hover the ✗ icon — tooltip shows the invalid version message
• Fix the value or clear it (normalises to *) — error clears, buttons re-enable

Preview

• Click Preview — dialog shows ide.properties content matching current state
• Verify disabled tools and their variables are absent from the preview
• Click Save from within the preview — file is written, both dialogs close

Save and file output

• After saving, open <project>/settings/ide.properties and verify:
  • IDE_TOOLS lists only enabled tools, names lowercased
  • _VERSION lines present for enabled tools with a version set
  • _EDITION lines present only for tools with supportsEdition=true
  • Variables for disabled tools are absent / removed
• Verify ide.properties.bak was created alongside the file

Edge cases

• Save with a tool that had a previous version entry but now has a blank
  version field — existing _VERSION line must be removed

---

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 29110111512

Coverage decreased (-0.1%) to 72.112%

Details

• Coverage decreased (-0.1%) from the base build.
• Patch coverage: No coverable lines changed in this PR.
• 29 coverage regressions across 1 file.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

29 previously-covered lines in 1 file lost coverage.

File	Lines Losing Coverage	Coverage
com/devonfw/ide/gui/MainController.java	29	63.64%

---

Coverage Stats

Relevant Lines:	17135
Covered Lines:	12868
Line Coverage:	75.1%
Relevant Branches:	7618
Covered Branches:	4982
Branch Coverage:	65.4%
Branches in Coverage %:	Yes
Coverage Strength:	3.18 hits per line

---

💛 - Coveralls

[quando632]

Thanks for the detailed write-up. Structure is solid (clean Service/Controller/Model split,
good service test coverage). Below are findings, cross-checked against the PR description.

---

Version validation diverges from the story (and contradicts your own test plan)

The PR states validation flags "a free-text entry that isn't in the loaded version list".
The code confirms this attachVersionValidation only does availableVersions.contains(...)
(plus a * exception). But the story explicitly requires pattern support: 2026.1* /
2026*! must be valid, and 2027* / 2026.1.2.4.5 must be detected as invalid by format.
With the current check:

• a valid pattern like 2026.1* is wrongly flagged (it's not literally in the list);
• malformed input like 2026.1.2.4.5 is only "not in list", not recognized as invalid format.

The CLI already has the right tool: VersionIdentifier.of(String), isPattern(), matches(...).
Validation should parse the input and, for patterns, matches() against the available versions.
This ideally lives in the service (so it's unit-testable), not in the cell.

Validation is skipped unless the dropdown was opened first breaks your test plan step

availableVersions is only populated in the version combo's setOnShowing handler. In
attachVersionValidation, when availableVersions == null the check is skipped entirely.
Typing into the editable combo does not trigger setOnShowing, so a user who types a value
and tabs away (without ever opening the dropdown) gets no red border and no error.

This directly contradicts the manual test: "Type a nonsense string into a version field, then
click away, red border and ✗ icon appear." That only passes if the dropdown was opened first.
Since onSave relies solely on the disabled button, invalid values can also be saved this way.

---

Changing edition doesn't re-validate the current version

On edition change the version list reloads, but the already-entered version and its error state
are not re-checked. A version valid for edition A may be invalid for edition B and stays unflagged
(or a stale red icon remains).

---

Window UI does not show everything

The window opens at half the screen height (new Scene(root, bounds/2, bounds/2) in App.java),
but the root layout is pinned to a fixed 515px (prefHeight="515.0" with maxHeight="-Infinity" and
minHeight="-Infinity" in main-view.fxml). When half the screen height is < 515px (common on
laptops), the 515px layout overflows the window and the bottom bar — i.e. the Cancel/Preview/Save
buttons is clipped and invisible until the user manually enlarges the window. The fixed
min/maxHeight should be relaxed (a BorderPane.bottom action bar is always reserved space anyway),
or the tab content given a sensible minimum height, so the primary action stays reachable.

---

PR description vs. implementation drift

The description mentions a spinner replacing the button text and a dialog that opens only once loaded, but the current code is a tab whose initialize() calls listToolConfigurations synchronously on the FX thread (only editions load in the background). Please align the description with the tab-based implementation, or move the initial load off the FX thread if blocking is a concern.

Tests

ToolSettingsServiceTest (32 tests) is thorough for the service preview generation, applyAndSave,
backup, edition/version loading incl. exception paths. The story's core requirement (version
validation, esp. patterns) is untested, because it lives in the cell/controller. Moving validation
into the service would let you unit-test 2026.1* valid / 2027* invalid / 2026.1.2.4.5 invalid,

---

[quando632]

State bug: validationErrors / currentContext are static

A new ToolSettingsController is created every time the tab is opened
(MainController.loadToolConfigContent). Because validationErrors is static, its state
outlives the instance. initialize() → updateButtonStates() reads the static set, so if an
error is left in it when closing, Save/Preview are wrongly disabled on the next open even
though the fresh tree shows no error. The comment justifies static with cell recycling, but the
cells already hold a controller reference, so an instance field survives recycling without
the leak. currentContext/service static are additional smells (not multi-window safe).

Edition combo: setManaged(true) while invisible

When supportsEdition == false, the combo is set setVisible(false) but setManaged(true), so
it still occupies layout space → visible gap in the column. Use setManaged(false) to collapse it.

[KarimALotfy]

Regarding the first point, you are absolutely right --> I've removed the static declarations from validationErrors, currentContext, and service

Regarding the second point, I left setManaged(true) intentionally. The goal was to preserve the layout structure so all rows remain aligned and tool entries with and without editions keep the same version-combobox width. In that case the empty space is expected

[KarimALotfy]

Thanks @quando632 for the comprehensive review and for taking the time to provide such detailed feedback and suggestions. Great job with the findings

I have addressed the points from your comment:

1. Created an isValidVersion(...) method in ToolSettingsService that handles the validation rules (including pattern validation), making the logic unit-testable and removing it from the UI layer.

2. Adjusted the version validation flow in ToolSettingsController, including when versions are loaded into the combo box and when validation is triggered, so validation also works without opening the dropdown first.

3. Updated the edition/version handling so that changing the edition reloads the available versions, repopulates the version combo box, and re-validates the current version accordingly.

4. Updated the PR description to match the current tab-based implementation.

5. Added new tests covering isValidVersion(...), including pattern and invalid-format scenarios.