In this recipe, we have looked at a number of different reload trigger configurations, so let's look at each of them individually to understand where best to use them:

• spring.devtools.restart.enabled: This property offers the simplest of controls, fully enabling or disabling the restart functionality of DevTools. With the value of false, no restart of the application will take place, regardless of the class or resource changes on the classpath.
• spring.devtools.restart.exclude: This property provides an ability to stop specific classpaths from being reloaded. This property accepts values in a comma-separated form using the Ant Path matching pattern style. The default exclude value is "META-INF/maven/**,META-INF/resources/**,resources/**,static/**,public/**,templates/**,**/*Test.class,**/*Tests.class,git.properties,META-INF/build-info.properties".
• spring.devtools.restart.additional-exclude: This property provides the convenience of being able to add to the default excludes list without having to copy/paste the default values, but rather simply adding to them while retaining the original defaults. It takes the same comma-separated Ant Path matching pattern style of input.
• spring.devtools.restart.additional-paths: This property provides the ability to watch for resources that are outside of the classpath. For example, this could be a config directory that gets loaded at application startup, and you want to restart the application if the config entry changes. It takes a comma-separated list of absolute file paths.
• spring.devtools.restart.poll-interval: This property specifies how long to pause, in milliseconds, between checking for classpath changes. The default value is 1000 milliseconds, but if there is a need to save some CPU cycles, this will do the trick.
• spring.devtools.restart.quiet-period: This property controls how much time should pass, in milliseconds, without any changes to the classpath before the restart will take place. This is needed to ensure the restarts don't get overwhelming if there are continuous changes taking place. The default value is 400 milliseconds, but it can be changed if needed.
• spring.devtools.restart.trigger-file: This property provides explicit control over when a restart happens by watching a trigger file for change. This is useful for situations where the classpath gets continuously changed, and you don't want to get caught in a restart loop.

All the preceding property settings listed are usually shared between all the application projects that developers work on, so DevTools provides the ability to have global properties defined in this, making it convenient to share the development configurations across many projects without having to copy/paste the same values in all the different codebases.

Another way to control reload triggers is with the use of META-INF/spring-devtools.properties with the restart.exclude.<name> and restart.include.<name> configurations inside them. By default, the restart of the application only gets triggered by changes to the actual classes or resources that are directly on the classpath and not bundled into JARs. This allows you to keep the majority of the classes in the non-reloadable base classloader, greatly limiting the number of entries that need to be monitored for changes.

In situations where developers work with multiple projects that are dependent on each other, or work in a multi-module repository, like the BookPub one, it might be desirable to add some JARs into a reloadable classloader and watch them for change. This would typically be applied to dependencies that point to the build/libs or target directories, where the JARs inside them are a direct result of a build task execution and typically get rebuilt frequently.

Another use case, which we explored in this recipe, is the inclusion or exclusion of build/classes or target/classes from the watch list. If a multi-module project is loaded in an IDE, it is common for the classpath to contain direct reference to the build directories of the sub-modules instead of the compiled JAR artifact, and depending on the use case, we might or might not choose to include or exclude those from triggering the reload.

The <name> part of the keys is not important as long as it is unique, because all the META-INF/spring-devtools.properties files will be loaded as composites, regardless whether if they live inside the JARs or right in the project. The suggested approach is to use a sub-module/artifact name, as it will typically ensure uniqueness. If more than one pattern applies, the name can be appended with a sequence number, for example restart.exclude.db-count-starter-1 and restart.exclude.db-count-starter-2. The value of each key should contain a valid regex pattern that can be evaluated against every entry in the classpath to determine whether that particular classpath URL should go into the reloadable or base classloader.