Hot deployment

Gretty supports hot deployment: whenever the classes, jars or resources [comprising the web-app] are updated, Gretty automatically reloads web-app.

Gretty version 0.0.18+ automatically recompiles and then reloads your web-app, as soon as source code files have changed.

Gretty version 1.0.0+ reloads the changed .class files "on-the-fly", without web-app restart. This is achieved with the help of springloaded library. By default this feature is turned off, you can activate it by setting managedClassReload=true.

Gretty version 1.1.5+ serves classes and resources of dependency projects directly from their buildDir, thus avoiding assembly/reload of jar files.

You can configure hot deployment by adjusting the gretty configuration properties:

  • scanInterval defines scan interval, in seconds. When set to zero, hot deployment is fully disabled.

  • scanDir defines one or more directories, scanned by hot-deployment. The directory could be a string or instance of java.io.File class, denoting relative (to the project) or absolute path.

  • onScan adds a closure to be called on hot-deployment scan, i.e. each scanInterval seconds. The function is called unconditionally, regardless of whether hot deployment detects changed files or not.

  • onScanFilesChanged adds a closure to be called whenever hot-deployment detects that files or folders were changed. The closure receives List<String> as the parameter, which holds full paths to all changed files and folders.

  • recompileOnSourceChange defines, whether the given web-app should automatically recompile on source change.

  • reloadOnClassChange defines, whether the given web-app should automatically reload when it’s compiled classes change. Note that setting reloadOnClassChange to false have no effect, if managedClassReload=true. That means: if managedClassReload is enabled, then all classes of all web-apps are live-reloaded, independently of reloadOnClassChange setting in individual web-apps.

  • reloadOnConfigChange defines, whether the given web-app should automatically reload when configuration files (either in WEB-INF or META-INF) change.

  • reloadOnLibChange defines, whether the given web-app should automatically reload when library files (either in WEB-INF/lib or in maven dependencies) change.

  • managedClassReload is boolean (default false). When true, the web-server will reload the changed .class files of the given web-app without web-app restart.

Gretty hot deployment assumes the following defaults:

  • scanInterval is set to one, that means that Gretty scans for changed files every second.

  • scanDir includes the following directories:

    • "${projectDir}/src/main/java"

    • "${projectDir}/src/main/groovy"

    • "${projectDir}/src/main/resources"

    • "${projectDir}/build/classes/main"

    • "${projectDir}/build/resources/main"

    • all dependency jars and overlay-WARs, comprising the web-app.

  • recompileOnSourceChange, reloadOnClassChange, reloadOnConfigChange and reloadOnLibChange are all set to true.

  • managedClassReload is set to false.

Tip
 Hot-deployment function normally serves files in "src/main/java" and "src/main/resources", but not in "src/main/webapp". This latter is processed by another function: Fast reload.
Tip
 Gretty supports hot deployment only on non-test gradle tasks. Any test tasks (including integration test tasks) run without hot deployment. The generated products also run without hot deployment.
Important
 Current implementation of hot deployment does not detect changes in Gradle configuration. That means: whenever you change and save "build.gradle", containing Gretty configuration, you need to restart the web-app "by hand", only then the changes will have effect.