#1937: link content from settings into workspace(s)

[tineff96]

This PR fixes #1937

Implemented virtual settings repository feature. A settings.properties without
git_url now indicates a virtual repository that reuses the already cloned
$IDE_HOME/settings folder. Sub-folders from settings can be linked into
workspaces via the link property, e.g.:

workspaces=*
link=ai=.github

This avoids the need to create and maintain separate git repositories for
shared configuration content.

Implemented changes:

• Added isVirtualSettingsRepository() to RepositoryConfig — returns true
  when id=settings and no git_url is set
• Added createSettingsRepositoryLinks() to RepositoryCommandlet — iterates
  over all configured workspaces and creates symlinks
• Added linkTargetExists() to RepositoryCommandlet — validates link target
  exists before creating symlink, logs warning and skips if not
• Relaxed git_url validation in RepositoryProperties for virtual settings
  repositories
• Added unit test testSetupVirtualSettingsRepository()

---

Testing instructions

Automated test

A JUnit test was added for this feature and can be executed with:

mvn -pl cli "-Dtest=RepositoryCommandletTest#testSetupVirtualSettingsRepositoryWithoutGitUrlWithLinks" test

The test verifies that a virtual settings repository without git_url can create configured links from the settings directory into the workspace.

Manual test

1. Create a subfolder in $IDE_HOME/settings/, e.g. ai/, with any file inside.

2. Create $IDE_HOME/settings/repositories/settings.properties with content:

workspaces=*
link=.github=ai

Note: no git_url property is required. This is intentional for a virtual settings repository.

3. Run:

ide repository setup

4. Verify that .github is a link pointing to $IDE_HOME/settings/ai/ in every workspace under $IDE_HOME/workspaces/.

5. Run ide repository setup a second time. It should complete without errors.

6. Change the link target to a non-existing folder, e.g.:

link=.github=nichtvorhanden

Run again. It should log that the target does not exist and skip the link without crashing.

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 27932932623

Coverage increased (+0.003%) to 71.384%

Details

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

Uncovered Changes

No uncovered changes found.

Coverage Regressions

33 previously-covered lines in 3 files lost coverage.

File	Lines Losing Coverage	Coverage
com/devonfw/tools/ide/git/repository/RepositoryCommandlet.java	24	73.43%
com/devonfw/tools/ide/git/repository/RepositoryProperties.java	8	89.31%
com/devonfw/tools/ide/version/VersionSegment.java	1	90.03%

---

Coverage Stats

Relevant Lines:	16283
Covered Lines:	12120
Line Coverage:	74.43%
Relevant Branches:	7302
Covered Branches:	4716
Branch Coverage:	64.59%
Branches in Coverage %:	Yes
Coverage Strength:	3.15 hits per line

---

💛 - Coveralls

[tineff96]

Note: mvn clean test fails with 7 errors in InstallCommandletTest on Windows.
This is a pre-existing issue unrelated to this PR, reproducible on main branch
and a second Windows machine. Tracked in #1985.

[hohwille]

@tineff96 thanks for your PR. You found the right spots and your changes to config and properties seem perfect. 👍
I added some review comment to better reuse existing code avoiding redundancies.
Since you add a new feature, could you also add a JUnit test method covering it?

[oanding-blrng]

I can verify, that all tests including the new one are running successfully. The manual test also worked as described.

The proposed changes look good so far, and I couldn't find anything to complain about. This PR can move on.

[hohwille]

@tineff96 thanks for your PR. You implemented the story properly and added a JUnit to cover the feature. Nice job 👍
I added some comments for further improvements.
Nothing is wrong with your code, I am just suggesting to solve few things slightly more elegant.

[hohwille]

IMHO this change is kind of pointless.
If we have a virtual settings repository then we can never enter the above if and then createRepository will always be true but since firstRepository will always be set nothing will be actually done here.
Therefore at this point this condition will always be true.
Nothing really wrong but confusing me if the condition is pointless.

[hohwille]

Actually the constant SETTINGS_REPOSITORY_KEYWORD was introduced as a duplicate to the already existing constant FOLDER_SETTINGS.
IMHO we should remove the duplicated constant, but that was not added by you...

Suggested change

	return IdeContext.SETTINGS_REPOSITORY_KEYWORD.equals(this.id)
	return IdeContext.FOLDER_SETTINGS.equals(this.id)

[hohwille]

actually nothing wrong here, but it would be more elegant to move this code:

    String filename = filePath.getFileName().toString();
    final String id;
    if (filename.endsWith(IdeContext.EXT_PROPERTIES)) {
      id = filename.substring(0, filename.length() - IdeContext.EXT_PROPERTIES.length());
    } else {
      id = filename;
    }

to a method String getId() in this class.
Then you do not need this constant and can implement isSettingsProperties() as:

  return IdeContext.FOLDER_SETTINGS.equals(getId());