#1976: extend tool commandlet installation logic

[Caylipp]

This PR fixes #1976

Implemented changes:

• Added ignoreProject support to ToolInstallRequest
• Added CLI option --ignore-project to InstallCommandlet
• Updated dependency installation to skip project symlinks when ignoring project or outside project context
• Updated GUI launcher dependencies to install in the software repository
• Added tests for ignore project flag and inheritance

---

Testing instructions

1. Run ide install java --ignore-project inside an IDEasy project and verify Java is installed in the
   software repository without creating a symlink under software/java.
2. Run ide install java --ignore-project outside any project and verify the tool is installed in the
   software repository.
3. Run added tests.

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"

[quando632]

Nice work on this 👍 The ignoreProject flag is threaded cleanly through ToolInstallRequest the standalone-vs-project branching in installAsDependency reads clearly, and I like that the skip path is covered by explicit tests for both the in-project and outside-project cases. Left a few inline comments the main one is about how the CLI flag is declared. 🙂

[coveralls]

Coverage Report for CI Build 30836475917

Coverage increased (+0.01%) to 72.628%

Details

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

Uncovered Changes

No uncovered changes found.

Coverage Regressions

92 previously-covered lines in 5 files lost coverage.

File	Lines Losing Coverage	Coverage
com/devonfw/tools/ide/tool/LocalToolCommandlet.java	38	80.24%
com/devonfw/tools/ide/tool/ToolCommandlet.java	27	73.99%
com/devonfw/tools/ide/tool/ToolInstallRequest.java	18	71.88%
com/devonfw/tools/ide/tool/gui/Gui.java	8	19.23%
com/devonfw/tools/ide/tool/ide/IdeToolCommandlet.java	1	78.69%

---

Coverage Stats

Relevant Lines:	17252
Covered Lines:	13068
Line Coverage:	75.75%
Relevant Branches:	7649
Covered Branches:	5017
Branch Coverage:	65.59%
Branches in Coverage %:	Yes
Coverage Strength:	3.22 hits per line

---

💛 - Coveralls

[quando632]

(superseded - see the inline comments.)

[quando632]

(superseded - see the inline comments.)

[quando632]

After my earlier comments I went through every project-dependent input in the install path instead of reporting findings one at a time. The pattern is structural, so I think it is worth looking at as a whole rather than as separate bugs

[quando632]

Thanks for the fast turnaround 🙌 All five points are addressed the isIdeHomeRequired split, the completeRequestRequested version fix, the guarded setVersion, the rewritten test, and the CliException for isIgnoreSoftwareRepo tools. I checked out the current head and the affected suite is green (18 tests, BUILD SUCCESS).

One small open question, no blocker: should --ignore-project also ignore the configured edition (getConfiguredEdition() is still used unconditionally), or is version-only intended? Happy either way just let me know and I'll approve.

[Caylipp]

Thanks for checking. Version-only is intended for this issue, so the configured edition should remain unchanged.

[hohwille]

@Caylipp thanks for your PR. Nice solution and good job 👍
I was actually looking for the place where tool dependencies get processed and wanted to check that you did not forget to set the flag from the parent request but you nicely solved that already in the ToolInstallRequest constructor what is more elegant so it is automatically inherited but could still be changed after construction in an edge-case. Very nice!

I did not expect that we expose this feature via the CLI to end-users. Have a look at my comments and lets see if we should revet this making this PR quite smaller or if we see value in it and should keep it.

BTW: While reviewing the Gui commandlet again via this PR, I was wondering, why we have to trigger installation of both java and mvn explicitly there even though mvn has a dependency to java. If I am not mistaken, we could now remove that (the redundant java installation) and before that was only a workaround because this story was not implemented.
Feel free to consult @laim2003 - in case we still need this redundant dependent java installation explicitly, it would be worth adding a comment why we need it.