Improve devtools trigger-file documentation

[forketyfork]

The devtools documentation for Spring Boot 2.1.6 proposes to use a "trigger file" in case of incremental compilation in the IDE, to make sure we upload all class file changes only at a specific time. The docs state the following:

Changing the file only triggers the check and the restart only occurs if Devtools has detected it has to do something. The trigger file can be updated manually or with an IDE plugin.

To use a trigger file, set the spring.devtools.restart.trigger-file property to the path of your trigger file.

From this I expected that the file may be put anywhere on the filesystem and monitored by the watcher, and upon its change the accumulated changes in the classpath folders are uploaded to the server.

While examining the source code of Devtools, I've discovered that:

• this property value is used in the TriggerFileFilter class for matching, however, not as a full path, but as a simple file name
• this filter is used to filter out the changes in the monitored classpath directories only, and consequently trigger reload only on this specific file change

If my understanding is correct, I believe it's worth adjusting the docs as follows:

• explicitly state that the spring.devtools.restart.trigger-file property is a simple file name, not a path
• state that the file has to be located on the application classpath
• provide an example on how to automate the update of this file both for local and for remote devtools setup, by elaborating on the mentioned "IDE plugin" functionality (through some extensive googling, I've found that the Spring Boot run configuration in IntelliJ IDEA is capable of producing and updating the trigger file when running devtools in local mode, but I don't believe there's something similar for the remote mode, so it would be nice to refer to a working example)

[philwebb]

Thanks for reporting this @forketyfork. I've tried to clarify things for the next release. I added a small note about IDE support but didn't add any comment about the remote mode in the end. I was worried about that information getting stale and I felt it would be better in the IDE documentation.