IntelliJ IDEA 2016.3 introduces the option to delegate the IDE build and run actions to Gradle. So if we invoke the Build Project action from the Build menu IntelliJ IDEA invokes the correct tasks using Gradle. Also the Run and Debug actions from the Run menu are executed with Gradle. Continue reading
In a previous post we learned how to create a class that extends
RuleSource with methods that define rules on how to create and change objects in the Gradle model space. With the
model configuration block in a build file we can also define creation rules for Rule based model configuration.
Rule based model configuration in Gradle allows us to have a graph of objects with dependencies that are resolved by Gradle. To make this work Gradle needs to know about the object in this model space. The model space is populated with objects of our own and with objects from Gradle. At time of writing this blog post we can not interact with the Gradle
Project object in our rule based model configuration. It is not officially part of the model space. Probably in the future this might change and will the
Project object managed by Gradle be part of the model space. Which means we can use then a
Project object as input parameter for any rule methods we have. For now the official way to pass project information to the rule based model space is via the
model configuration block in our build script. The
model configuration block can be used to set properties on objects with values from our
Rule based model configuration gives Gradle more knowledge about the objects and their dependencies. This information can be used by Gradle to optimise the build process. We define rules on how we want Gradle to create objects and how we want to mutate objects in a class that extends
RuleSource. We can also add rules to validate objects available in the Gradle model space. We use the
@Validate annotation on methods that have validation logic. The first argument of the method is of the type of the object we want to validate. This type must be managed by Gradle.
Gradle 3.2 deprecates the
<< operator to add actions to a task. The
<< operator maps to the
leftShift method of a task. This operator confuses a lot people that are new to Gradle. Because without the operator we are configuring a task instead of adding actions. I can tell from experience the mistake is easily made. If we use the
<< in our build script with Gradle 3.2 we get a warning on the console. The warning message already mentions a solution: use the
doLast method to add actions.
When we use Rule based model configuration in our Gradle project we can give Gradle rules on how to manage objects from the model space. These rules are defined in a class that extends
RuleSource. When we want to set some default values for properties of a model object (in Gradle terms this is a subject) we can use the
@Defaults annotation. Rules annotated with
@Defaults are invoked right after the object is created and before any other methods that can mutate the state of the object.
The method, to set the default values, must have the type of the object as first parameter. Other parameters are considered input parameters and can be used to set a default value based on other model objects.
We use the
model task to see which objects are available in the Gradle model space. The model spaced is managed by Rule based model configuration. Objects can be defined as hidden by the object author(s). By default a hidden object is not shown in the model report. We must use the task option
--showHidden to show also the hidden objects in the model report.
model task shows the objects in the model space of Gradle. The output shows the object hierarchy. By default a full report is shown, with a lot of information. We can customize the output format with the
--format task argument. The default value is
full, but we can also use the value
short. With the value
short a lot less information is shown.
Gradle has an incubating feature Rule based model configuration. This is a new way to configure Gradle projects where Gradle has more control of the configuration and the dependencies between configuration objects. This allows Gradle to resolve configuration values before they are used, because Gradle knows there is a dependency. With this new model we don’t need any lazy evaluation “tricks” we had to use. For example there was an internal convention mapping mechanism for tasks to assign values to a task configuration after the task was already created. Also the
project.afterEvalute is a mechanism to have late binding for task properties. With the new rule based model Gradle can do without these options, we can rely on Gradle resolving all dependent configuration values when we create a task.
To apply a plugin in our Gradle build script we can use the plugins DSL. The plugins DSL is very concise and allows Gradle to be more efficient and more in control when loading the plugin. Normally the plugin we define is fetched from the Gradle plugin portal. If we have our own repository, for example on the intranet of our company, we have to define that extra repository with a
pluginRepositories configuration block in the
settings.gradle file of our project.