Always re-import the entire project after executing the gradle task

[mozhuanzuojing]

Extension Name: vscode-gradle
Extension Version:3.6.1
OS Version:Windows_NT x64 10.0.19043
VSCode version:1.60.0-insider (system setup)

Describe the bug
Always re-import the entire project after executing the gradle task

To Reproduce
Use vscode to open a gradle project normally. Wait for the compilation to complete.
Open gradle view to execute any task. Observe the terminal to execute the imported project again

Expected behavior
Do not reimport the project

Screenshots

Output from "Gradle Tasks"
2.log

Does the bug still exist if you disable all other extensions?
Yes

Additional context
Add any other context about the problem here.

[mozhuanzuojing]

@CsCherrYY This phenomenon is related to another issue #930

Because opening Gradle View will reopen a new Gradle Deamon JVM. Then recompile the entire project. This wastes a lot of time.
Can this problem be fixed as soon as possible because it will affect development work.

additional

• And the Deamon JVM started by vscode-gradle does not use the parameter java.import.gradle.user.home

[CsCherrYY]

Just tried a sample gradle project: https://docs.gradle.org/current/samples/zips/sample_building_spring_boot_web_applications-groovy-dsl.zip, execute app: build in the gradle tasks view and can't reproduce this issue.

I think it's probably because your executed task affects some build files (e.g. build.gradle). It triggers vscode-java to re-import your project.

Because opening Gradle View will reopen a new Gradle Deamon JVM. Then recompile the entire project.

IMO opening Gradle View is more like "configure" the project than "recompile", it will cost less time than recompiling project. As you mentioned in #930 (comment), vscode-gradle indeed starts a different Gradle daemon from vscode-java does. Do you mean to let vscode-gradle reuses the same Gradle Daemon started by vscode-java? If yes, I think it might be a good way to go. Since they are two different extensions it also needs further investigation and collaboration.

additional

• And the Deamon JVM started by vscode-gradle does not use the parameter java.import.gradle.user.home

Currently we find a bug about getting daemon status process. This process now started the wrapper without the parameter java.import.gradle.user.home, and the bug will be fixed in #931. I'm not greatly confident about whether it is related to this issue you find, could you just provide a sample project so I can reproduce this issue?

Update:I just tried spring-boot and can't reproduce this issue. IMO it's related to your project. A sample project can reproduce this issue would be very helpful.

[mozhuanzuojing]

IMO opening Gradle View is more like "configure" the project than "recompile", it will cost less time than recompiling project. As you mentioned in #930 (comment), vscode-gradle indeed starts a different Gradle daemon from vscode-java does. Do you mean to let vscode-gradle reuses the same Gradle Daemon started by vscode-java? If yes, I think it might be a good way to go. Since they are two different extensions it also needs further investigation and collaboration.

I hope that the vscode-gradle plugin will not start a new Deamon, just use the existing Gradle Deamon. Because my project is so big, I have to wait a long time every time. If you don’t change it, I can only give up using it!

[mozhuanzuojing]

Currently we find a bug about getting daemon status process. This process now started the wrapper without the parameter java.import.gradle.user.home, and the bug will be fixed in #931. I'm not greatly confident about whether it is related to this issue you find, could you just provide a sample project so I can reproduce this issue?

This is the same problem. thanks

[CsCherrYY]

Currently we find a bug about getting daemon status process. This process now started the wrapper without the parameter java.import.gradle.user.home, and the bug will be fixed in #931. I'm not greatly confident about whether it is related to this issue you find, could you just provide a sample project so I can reproduce this issue?

This is the same problem. thanks

we plan to release 3.7.0 this week including this fix. You can try if this works for you project.

[mozhuanzuojing]

Currently we find a bug about getting daemon status process. This process now started the wrapper without the parameter java.import.gradle.user.home, and the bug will be fixed in #931. I'm not greatly confident about whether it is related to this issue you find, could you just provide a sample project so I can reproduce this issue?

This is the same problem. thanks

we plan to release 3.7.0 this week including this fix. You can try if this works for you project.

👌

[mozhuanzuojing]

Update:I just tried spring-boot and can't reproduce this issue. IMO it's related to your project. A sample project can reproduce this issue would be very helpful.

i also will test it use springboot. Wait for my message

[mozhuanzuojing]

@CsCherrYY Thanks!

Disable the gradle plugin, restart VS Code, and then enable the gradle plugin. The problem does not recur after repeating twice.

additional, i add following config

"java.configuration.updateBuildConfiguration": "disabled",
"java.debug.settings.forceBuildBeforeLaunch": false