-
Notifications
You must be signed in to change notification settings - Fork 408
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
saving non-Java file under source folder leads to rebuild #3120
Comments
I'm able to reproduce. Here's what I see so far : The reason the build is triggered seems like a side effect. Line 223 in df60479
The code ends up there and that method triggers the diagnostics clearing + the rebuild at : eclipse.jdt.ls/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/JDTUtils.java Line 1260 in df60479
Maybe we need to find a way to avoid that side effect. I'll need to look further to figure out how that triggers the rebuild. I'm thinking of examples like Protobuf, where being able to trigger rebuilds from changes to non-Java files is needed, but if this doesn't contribute to that, then we should prevent it from happening. |
Nevermind. @snjeza pointed out that this is an incremental autobuild. No other classfiles get rebuilt (I checked timestamps). Simply the non-Java file gets updated (copied) into the output folder. I think we can probably close this, although it's a bit strange for the autobuild side effect to be purely a result of refreshing the parent in a utility method that simply returns the resource of a uri. |
@rgrunber I am wonder may the side effect caused dead loop. Say in a maven project, front engineer put some front source files (less, ts etc) in src/main/webapp/, and use maven plugin |
A similar issue was reported at redhat-developer/vscode-java#3639 . Although that one seems different in that the file being refreshed is in the target folder, though it is a non-source file generated by the build. |
When I create a
foo.ts
file insrc
folder, and I save it, there is aworkspace/didChangeWatchedFiles
which seems retrigger the project build.It is because JDT LS returns this following glob pattern:
@rgrunber told me that you did that perhaps to support generated files. I wonder if you should avoid triggering a build if it is not a java files?
Here my LSP traces:
The text was updated successfully, but these errors were encountered: