Spring Boot version: 2.2.4.RELEASE Gradle version: 6.0.1 Clean project created inside IntelliJ IDEA (2019.3) via the initializr., with the devtools dependency added.

The devtools docs state that a restart only occurs on some classpath changes. Especially following paths are excluded by default: /META-INF/maven,/META-INF/resources,/resources,/static,/public,/templates and should not trigger a restart but should reload.

When using the default settings of IntelliJ and running the application via its internal run configuration the build process is delegated to gradle. Thus everything related to processing resources, running annotation processors and compiling java classes is delegated to the gradle process. Now the infuriating things are happening: Even when modifying an excluded file, like templates/index.html the whole application restarts. It seems like, gradle is always copying ALL resources to the output (build) directory and so the devtools file change listener registers them as "modified" but they are not.

Using the Update action inside IntelliJ does not help. Even using the trigger file method will always result in a complete restart. Using update resources does not help either. See the jetbrains docs for more information.

I do not know, if this is fixable with an gradle option or if the devtools need an more sophisticated process to detect changes. It seems it only compares filesize, and timestamp of files.

Simple demo app, created with the initializr: demo_app.zip

Comment From: bclozel

I've reproduced this issue. IDEA indeed delegates this task to Gradle directly by calling the :processResources task on the project. Gradle's ProcessResources task is quite straightforward: it cleans completely the output of the previous task run and processes all resources.

I guess this task could be improved and its incremental support could be more fine-grained, but I think that:

  • it might not have been raised to the Gradle team (at least I couldn't find an instance of this issue in their tracker)
  • processing resources implies annotation processors, and resource filtering so this might more complex than we think

I don't know how the process detecting changes for devtools could be made more sophisticated. Filesize and timestamps are already quite advanced, and I fear that trying to do more without participating in the build itself is not the right path.

I believe that reaching out to the Gradle team for this might be the best option. Could you create an issue for that and point back here for context?

Comment From: Dazzel

Running the annotation processors and such in the build process without configuring the IDE made us switch to using gradle instead of the in-build process. So it would be a major annoyance to switch back to using the IDEs process.

I could not find any instance of this issue either so I figured I'll let the spring team know first and see what may be done on this side of the process.

I'll raise an issue in the gradle project and link it back: https://github.com/gradle/gradle/issues/12220

Comment From: bclozel

I'll close this issue for now as I don't see how we could improve the situation in Spring Boot. We can of course reopen it if anybody has a workaround/improvement idea for devtools here.

Comment From: wilkinsona

The only thing that I can think of is to hash the files to see if their content has changed. That wouldn't add much complexity, but it may be prohibitively slow in an app with a process resources task that outputs a large number of files.

Comment From: Dazzel

Still nothing in the works on the gradle side..

Is it possible to give it another shot or raise the attention there @bclozel or @wilkinsona ?