One of the command line options of Gradle is --offline. With this option we run Gradle in offline mode to indicate we are not connected to network resources like the internet. This could be useful for example if we have defined dependencies in our build script that come from a remote repository, but we cannot access the remote repository, and we still want to run the build. Gradle will use the locally cached dependencies, without checking the remote repository. New dependencies, not already cached, cannot be downloaded of course, so in that scenario we still need a network connection.
We can check in our build script if the --offline command line argument is used. We can use this to disable tasks that depend on network resources so the build will not fail. To see if we invoked our build with the --offline option we can access the property gradle.startParameter.offline. The value is true if the command line argument --offline is used and false if the command line argument is not used.
To quickly start with a Spring project we can use the website start.spring.io. Via a user interface we can set project properties and at the end we have a project archive (Zip or gzipped Tar file) or build file (pom.xml or build.gradle). We can also directory access an URL to create the output files and we set the properties via request parameters. This way you can share a link with someone and if they click on it they will download the generated project archive or build files.
When we create our own custom tasks we might need to support lazy evaluation of task properties. A Gradle build has three phases: initialisation, configuration and execution. Task properties can be set during the configuration phase, for example when a task is configured in a build file. But our task can also evaluate the value for a task property at execution time. To support evaluation during execution time we must write a lazy getter method for the property. Also we must define the task property with def or type Object. Because of the Object type we can use different types to set a value. For example a Groovy Closure or Callable interface implementation can be used to execute later than during the configuration phase of our Gradle build. Inside the getter method we invoke the Closure or Callable to get the real value of the task property.
Suppose we use the Gradle apply from: statement to import another Gradle build file into our build file. The external build file uses a Gradle plugin that needs a buildscript block to define the classpath configuration with the classes needed for the plugin. We cannot use the plugin id inside our external build script to use it, but we must use the type of the plugin. Otherwise Gradle cannot resolve the plugin from the main build file.
To define project properties outside the Gradle build file, we can define them in a file gradle.properties in our project directory. If we want to define property values that are used by all Gradle builds we can create a file gradle.properties in the GRADLE_USER_HOME directory. By default this is in the USER_HOME/.gradle directory.
Gradle has an idea and eclipse plugin that we can use to configure IntelliJ IDEA and Eclipse project files. When we apply these plugins to our project we get extra tasks to generate and change project files. Inside our Gradle build file we get new configuration blocks to specify properties or invoke methods that will change the configuration files. One of the nice things to add is to let the IDE download Javadoc files for dependencies in our Java/Groovy projects. By default the sources for a dependency are already downloaded and added to the project, but Javadoc files are not downloaded.
To start Grails in interactive mode we simply type grails on the command line. This starts Grails and we get an environment to run Grails commands like compile and run-app. Since Grails 3 the underlying build system has changed from Gant to Gradle. We can invoke Gradle tasks in interactive mode with the gradle command. Just like we would use Gradle from the command line we can run the same tasks, but this time when Grails is in interactive mode. Grails will use the Gradle version that belongs to the current Grails version.
We even get TAB completion for Gradle tasks.
In a previous post we learned that configuration property values can be passed via environment variables. With Spring Boot we can also pass the values using Java system properties. So if we have a property sample.message then we can use -Dsample.message=value to pass a value when we run the application. If we use the Spring Boot Gradle plugin we must reconfigure the bootRun task to pass Java system properties from the command-line.
Gradle is of course a great build tool for Java related projects. If we have tasks in our projects that need to execute a Java application we can use the JavaExec task. When we need to pass Java system properties to the Java application we can set the systemProperties property of the JavaExec task. We can assign a value to the systemProperties property or use the method systemProperties that will add the properties to the existing properties already assigned. Now if we want to define the system properties from the command-line when we run Gradle we must pass along the properties to the task. Therefore we must reconfigure a JavaExec task and assign System.properties to the systemProperties property.