#1695: Clone settings to temporary directory, analyse, and then move by areinicke · Pull Request #1878 · devonfw/IDEasy

areinicke · 2026-04-30T06:40:04Z

This PR fixes #1695

Implemented changes:

When creating a new project, the settings or code repository is first cloned to a temporary location (at $IDE_ROOT/_ide/tmp/projects/<project name>) where it is analyzed for validity. We check whether an ide.properties file exist either at the top level or within a settings folder at the top level. Only if this passes, do we create a new project at $IDE_ROOT/<project name> and move the files from the temporary location to the final location. The temporary folder is fully deleted after this process.
Removed the --code option when creating a project. We now automatically determine if the repository is a code or settings repository and act accordingly.

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#

Note: In some places, I used getFileAccess() to copy and subsequently delete files. I am aware that there is a move function. However, this was always failing for some reason

coveralls · 2026-04-30T08:43:56Z

Coverage Report for CI Build 28849265105

Coverage decreased (-0.1%) to 71.962%

Details

Coverage decreased (-0.1%) from the base build.
Patch coverage: No coverable lines changed in this PR.
44 coverage regressions across 4 files.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

44 previously-covered lines in 4 files lost coverage.

File	Lines Losing Coverage	Coverage
com/devonfw/tools/ide/commandlet/AbstractUpdateCommandlet.java	20	80.54%
com/devonfw/tools/ide/commandlet/CreateCommandlet.java	11	81.01%
com/devonfw/tools/ide/context/IdeContext.java	7	70.63%
com/devonfw/tools/ide/git/GitUrl.java	6	69.49%

Coverage Stats


Relevant Lines:	16563
Covered Lines:	12418
Line Coverage:	74.97%
Relevant Branches:	7426
Covered Branches:	4845
Branch Coverage:	65.24%
Branches in Coverage %:	Yes
Coverage Strength:	3.18 hits per line

💛 - Coveralls

…verification

…n' of https://github.com/areinicke/IDEasy into feature/1695-clone-settings-to-temp-dir-for-verification

Co-authored-by: Robin Wenzel <robin@die-wenzels.de>

hohwille

@areinicke thanks for your PR. Great that you implemented a test for it and finally started improving GitContextMock what I suggested long time ago when GitContextMock was supposed to be implemented. 👍
This is not a very easy task. Seems in such cases it makes sense to start with a design session before doing the complete PR implementation in the future...
However, should still not be a big change since most of your PR is already perfectly correct.

hohwille · 2026-05-17T14:06:19Z

+      // Check if instance of create commandlet. Only then will we analyze the project
+      if (this instanceof CreateCommandlet) {
+        analyzeProject();
+      }


This design can be improved.
Option 1: you assume that you only need to analyse this when a project is initially created but not when updated.

Then simply override updateSettings() in CreateCommandlet and call analyseProject() after super.updateSettings(). Then only CreateCommandlet knows of analyseProject() (SoC).

Option 2: you need to analyse whenever you need to clone the settings.

Then this code is wrong since you skip this in case of UpdateCommandlet.
In such case you would need to do this after the cloning of the settings.

IMHO the option to ask for the settings in case of ide update is a kind of auto-repair feature of IDEasy.
Therefore ide update should behave also in the same way that it detects if we cloned an regular settings repo or a code repo with settings included.
But to get all this clean, we might need to revisit the design how create and update try to reuse the existing code/methods from AbstractUpdateCommandlet.
IMHO it would be better to do this on create:

prepare a temp folder

trigger the reusable functionality that clones the settings into a given project folder where here we provide the temporary folder. If it detected a code repo, it can move the settings to main workspace and proper folder name from the GitUrl and create the symlink to preserve a proper settings folder in the projects root dir.

if that fails (neither regular settings repo nor code repo with settings found) we cleanup and abort.

if that succeeded we can move the temp folder to the real project folder and continue with the regular logic where we re-initialize the IdeContext on the real project and do the full create/update process.

In case of ide update we can keep everything as is and reuse the same functionality described above in the 2nd point.

This point is still not addressed. The developer taking over this PR should keep the project renaming (move) locally inside the CreateCommandlet and not do this in this class that then makes assumptions about very specific implementation details of CreateCommandlet that do not make any sense for UpdateCommandlet that also extends from this class.

Then simply override updateSettings() in CreateCommandlet and call analyseProject() after super.updateSettings(). Then only CreateCommandlet knows of analyseProject() (SoC).

From what I can tell this point has already been implemented. Regarding the other points i'm still looking into it.

Yes, Option 1 has already been implemented by @areinicke

hohwille · 2026-05-17T14:18:54Z

+      // Repository seems to be invalid. Clean up temporary location and return error
+      fileAccess.delete(this.context.getIdeHome());
+      throw new CliException("This repository does not include an " + EnvironmentVariables.DEFAULT_PROPERTIES + " or " + EnvironmentVariables.LEGACY_PROPERTIES + " file at the top level or a settings folder with such a file. "
+      + "The repository does not seem to be a valid IDEasy repository. Please verify the repository and try again.");


dont delete the entire project.
You can either delete the settings here or IMHO even better would be to just return failure (e.g. false while otherwise true is returned for success) and let the calling logic handle the cleanup so in case of ide update we can just delete the settings and in case of ide create we can delete the temp project.

This only deletes the temporary location if the verification fails. Why shouldn't that one be deleted if it is invalid anyway?

this.context.getIdeHome() usually gives me my project home e.g. ~/projects/IDEasy.

This code is used for ide create and for ide update. You are assuming that this will refer to some temporary directory since you are thinking of your changes in ide create but for ide update your assumption is wrong.

If the project become "invalid" this can have many reasons. Maybe by accident the user deleted some file or folder. fileAccess.delete is a destructive operation. If you as a user will run into the situation that your entire ~/projects/IDEasy folder gets deleted and all your uncomitted work is gone because IDEasy due to some mistake thought that something is "invalid" you might not like the result ;)

Believe me - we already had all such situations and I do not want to go there again.
If we "delete" user content like entire IDE projects or workspaces and we have a real reason to do so, we should use fileAccess.backup since then the data is still there and the user could somehow recover his work in case of an accident.
However, I am still convinced that this is wrong. Keep your clenup of temporary directory only in CreateCommandlet where you created it and can ensure you do not cause severe harm.

This recommendation has also already been implemented

…verification

…n' of https://github.com/areinicke/IDEasy into feature/1695-clone-settings-to-temp-dir-for-verification

…verification

hohwille · 2026-07-20T18:40:35Z

+
+

Suggested change

hohwille · 2026-07-20T18:42:17Z


    String newProjectName = this.newProject.getValue();
    Path newProjectPath = this.context.getIdeRoot().resolve(newProjectName);
+    Path tempProjectPath = this.context.getIdeRoot().resolve("_ide/tmp/projects").resolve(newProjectName);


Suggested change

Path tempProjectPath = this.context.getIdeRoot().resolve("_ide/tmp/projects").resolve(newProjectName);

Path tempProjectPath = this.context.getTempPath().resolve(IdeContext.FOLDER_PROJECTS).resolve(newProjectName);

hohwille · 2026-07-20T18:47:52Z

+    Path tempProjectPath = this.context.getIdeRoot().resolve("_ide/tmp/projects").resolve(newProjectName);

    LOG.info("Creating new IDEasy project in {}", newProjectPath);
    if (!this.context.getFileAccess().isEmptyDir(newProjectPath)) {


IMHO we should also check the final target project folder for existence.
If we call ide create IDEasy - but $IDE_ROOT/IDEasy already exists, do we want to create a new IDEasy project in tmp folder and then populate everything in order to then fail when we want to move the project?
If the target project already exists, we should not create at all and fail. The user can then call ide update on the target project or he can do rm -rf «project» if the project is totally broken and he wants to recreate it.

hohwille · 2026-07-20T18:50:44Z

+    // assert
+    Path newProjectPath = context.getIdeRoot().resolve(NEW_PROJECT_NAME);
+    assertThat(newProjectPath).doesNotExist();
+    assertThat(context.getIdeRoot().resolve("_ide/tmp/projects").resolve(NEW_PROJECT_NAME)).doesNotExist();


Suggested change

assertThat(context.getIdeRoot().resolve("_ide/tmp/projects").resolve(NEW_PROJECT_NAME)).doesNotExist();

assertThat(context.getTempPath().resolve(IdeContext.FOLDER_PROJECTS).resolve(NEW_PROJECT_NAME)).doesNotExist();

hohwille · 2026-07-30T16:28:52Z

@laim2003 what is the state of this? Can you finally complete this PR or hand it over to someone else completing it.
This PR was created 1/4 year ago and it should be completed and finally merged.

…fw#1878

laim2003 · 2026-08-03T09:27:37Z

The new PR implementing these changes can be found under: #2249

areinicke added 3 commits April 27, 2026 13:16

WIP Commit

a122556

Update logic

c497948

Removed --code option & Added further functionality

54a1fed

github-project-automation Bot added this to IDEasy board Apr 30, 2026

github-project-automation Bot moved this to 🆕 New in IDEasy board Apr 30, 2026

areinicke self-assigned this Apr 30, 2026

areinicke moved this from 🆕 New to 🏗 In progress in IDEasy board Apr 30, 2026

areinicke added enhancement New feature or request create Create commandlet used to create new IDEasy projects with "ide create" settings ide-settings repo and replated processes and features git git version management tool integration labels Apr 30, 2026

Fix tests

90e43e7

areinicke added 8 commits April 30, 2026 10:44

Merge branch 'main' into feature/1695-clone-settings-to-temp-dir-for-…

5dba7b5

…verification

Update comments

aa751ff

Merge branch 'feature/1695-clone-settings-to-temp-dir-for-verificatio…

b19c6eb

…n' of https://github.com/areinicke/IDEasy into feature/1695-clone-settings-to-temp-dir-for-verification

formatting cleanup

3e936dc

Minor code refactor

9bee5f1

Update comments

29f6d1f

Update changelog

8b69339

Add test case for invalid repository

d1bfbf5

areinicke marked this pull request as ready for review April 30, 2026 10:08

areinicke moved this from 🏗 In progress to Team Review in IDEasy board Apr 30, 2026

areinicke added 2 commits April 30, 2026 12:18

Replace hard coded variables

64f1220

Fix tests

462d6d5

laim2003 self-assigned this Apr 30, 2026

laim2003 self-requested a review April 30, 2026 10:55

satorus self-assigned this Apr 30, 2026

satorus reviewed Apr 30, 2026

View reviewed changes

Apply suggestion from @satorus

373fc19

Co-authored-by: Robin Wenzel <robin@die-wenzels.de>

satorus approved these changes Apr 30, 2026

View reviewed changes

laim2003 suggested changes Apr 30, 2026

View reviewed changes

Comment thread cli/src/main/java/com/devonfw/tools/ide/commandlet/AbstractUpdateCommandlet.java Outdated

renamed method to follow coding conventions

154ff6c

areinicke moved this from Team Review to 👀 In review in IDEasy board Apr 30, 2026

areinicke requested a review from laim2003 May 6, 2026 08:49

laim2003 approved these changes May 6, 2026

View reviewed changes

hohwille requested changes May 17, 2026

View reviewed changes

hohwille and others added 6 commits May 17, 2026 16:39

Merge branch 'main' into feature/1695-clone-settings-to-temp-dir-for-…

6ce1e46

…verification

Step 1 Refactor

fcc2a0b

Merge branch 'main' into feature/1695-clone-settings-to-temp-dir-for-…

900c0f2

…verification

Finish Step 1 Refactor

45d35be

Merge branch 'feature/1695-clone-settings-to-temp-dir-for-verificatio…

9cfd047

…n' of https://github.com/areinicke/IDEasy into feature/1695-clone-settings-to-temp-dir-for-verification

Fixed temp location not being fully empty after projectr creation

0e82a26

areinicke moved this from 👀 In review to 🏗 In progress in IDEasy board May 27, 2026

Removed references to --code option in project creation

777b997

hohwille moved this from 🏗 In progress to 👀 In review in IDEasy board Jun 18, 2026

hohwille unassigned satorus Jun 30, 2026

areinicke and others added 3 commits July 7, 2026 09:21

Merge branch 'main' into feature/1695-clone-settings-to-temp-dir-for-…

b5e23a7

…verification

Remove ProjectNameConvention reference

36018b1

Merge branch 'main' into feature/1695-clone-settings-to-temp-dir-for-…

94c6511

…verification

hohwille reviewed Jul 20, 2026

View reviewed changes

hohwille added this to the release:2026.08.001 milestone Jul 20, 2026

hohwille unassigned areinicke Jul 21, 2026

maybeec mentioned this pull request Jul 26, 2026

prioritize PR overview by project board and fix stale changelog placement #2210

Open

8 tasks

laim2003 moved this from 👀 In review to 🏗 In progress in IDEasy board Jul 31, 2026

laim2003 added a commit to laim2003/IDEasy that referenced this pull request Aug 3, 2026

devonfw#1695: applied suggestions by @hohwille from original PR devon…

6320067

…fw#1878

laim2003 closed this Aug 3, 2026

github-project-automation Bot moved this from 🏗 In progress to ✅ Done in IDEasy board Aug 3, 2026

	Path tempProjectPath = this.context.getIdeRoot().resolve("_ide/tmp/projects").resolve(newProjectName);
	Path tempProjectPath = this.context.getTempPath().resolve(IdeContext.FOLDER_PROJECTS).resolve(newProjectName);

	assertThat(context.getIdeRoot().resolve("_ide/tmp/projects").resolve(NEW_PROJECT_NAME)).doesNotExist();
	assertThat(context.getTempPath().resolve(IdeContext.FOLDER_PROJECTS).resolve(NEW_PROJECT_NAME)).doesNotExist();

Uh oh!

Conversation

areinicke commented Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

This PR fixes #1695

Implemented changes:

Checklist for this PR

Uh oh!

coveralls commented Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Coverage Report for CI Build 28849265105

Coverage decreased (-0.1%) to 71.962%

Details

Uncovered Changes

Coverage Regressions

Coverage Stats

💛 - Coveralls

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

hohwille left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hohwille commented Jul 30, 2026

Uh oh!

laim2003 commented Aug 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

areinicke commented Apr 30, 2026 •

edited

Loading

coveralls commented Apr 30, 2026 •

edited

Loading