Grails 3, Gradle & Multi-Project Builds
One of the key new features of Grails 3 is the build system now being a set of plugins for the Gradle build tool.
The Grails 2.x build system was conceived when Gradle did not exist and the only options in the Java ecosystem were Ant and Maven, neither of which I felt was appropriate for a RAD framework.
Gradle on the other hand provides the flexibility and ease of use necessary, plus the power of multi project builds.
Unfortunately one area that has not worked well up until now is the developer experience when developing Grails applications using Gradle multi project builds.
With Grails 2 it was possible to define a series of inline plugins and have all of the features of those inline plugins available to the main application. The equivalent to this in the Gradle world is a multi-project build.
The issue with the way Gradle works however, is the default behaviour is to construct a JAR file for each subproject dependencies and place the JAR file on the classpath. So if you have a dependency like:
compile project(":anotherProject")
Gradle will build a JAR file from anotherProject and place that on the classpath. This is what you want when creating a production distribution, such as a runnable JAR for deployment. However, at development time this presents an issue.
Grails plugins are regular JAR files, but they provide a lot more possibilities than most frameworks. In addition to classes, they can contain GSPs, i18n message bundles and static assets. In fact they can contain a complete application that can be embedded within another application.
So what happens when Gradle builds a JAR file from a subproject that is a plugin? Well when a developer runs grails run-app they generally expect that changes they make to classes, GSPs, i18n message bundles and static assets will be reflected into the running application, without restarting.
Since Gradle has packaged all of these sources into a JAR file, including doing things like precompiling all GSP or GSON views into classes, they can no longer be changed. This impacts the developer experience, because every change you need to make to a subproject requires an application restart. Not what you want.
So today we released Grails 3.0.14 and Grails 3.1.1 and within those releases is a new feature that we have developed whilst working on a large client project. With this release you can can enable exploded mode and suproject plugins within your build.gradle as follows:
grails { exploded = true plugins { compile project(':anotherProject') } }
Then when you run the application with grails run-app instead of building a JAR file for each subproject instead it will place the classes and resources of the plugin directly on the classpath.
If you package the application for production deployment then the dependencies will still be packaged as JAR files, but at development time you benefit from the productivity features such as reloading of classes, views, i18n messages and so on for subprojects in the same way as inline plugins were reloadable in Grails 2.
In order to make this work we had to modify that artifacts Gradle produces when building a dependent project to be the classes directory. In addition the classpath for grails run-app had to be modified to also include the resources found in src/main/resources.
Hopefully one day Gradle includes an out-of-the-box solution for this, but for the moment what we have in place works and greatly improves the developer experience.
I also thought this was a nice example of how OCi is working with clients to understand their issues and add features to the framework that improve their productivity. Get in touch if you are looking for help and want to collaborate with us in making Grails better for everyone.
theartofmadeline
germansingergirl
kaledo-art
dailybridgerton
gummygunk
blakekathryn
snowghoul
origamiaround
dededos