Gradle command line java options

Passing Command Line Arguments in Gradle

If you have a few years of experience in the Java ecosystem, and you’re interested in sharing that experience with the community (and getting paid for your work of course), have a look at the «Write for Us» page. Cheers, Eugen

1. Overview

Sometimes, we want to execute various programs from Gradle that require input parameters.

In this quick tutorial, we’re going to see how to pass command-line arguments from Gradle.

2. Types of Input Arguments

When we want to pass input arguments from the Gradle CLI, we have two choices:

In general, we should use project properties unless we want to customize settings in the JVM.

Although it is possible to hijack system properties to pass our inputs, we should avoid doing this.

Let’s see these properties in action. First, we configure our build.gradle:

apply plugin: "java" description = "Gradle Command Line Arguments examples" task propertyTypes() < doLast< if (project.hasProperty("args")) < println "Our input argument with project property ["+project.getProperty("args")+"]" >println "Our input argument with system property ["+System.getProperty("args")+"]" > > 

Notice we read them differently in our task.

We do this because project.getProperty() throws a MissingPropertyException in case our property is not defined.

Unlike project properties, System.getProperty() returns a null value in case the property is not defined.

Next, let’s run the task and see its output:

$ ./gradlew propertyTypes -Dargs=lorem -Pargs=ipsum > Task :cmd-line-args:propertyTypes Our input argument with project property [ipsum] Our input argument with system property [lorem] 

3. Passing Command Line Arguments

So far, we’ve seen just how to read the properties. In practice, we need to send these properties as arguments to our program of choice.

3.1. Passing Arguments to Java Applications

In a previous tutorial, we explained how to run Java main classes from Gradle. Let’s build upon that and see how we can also pass arguments.

First, let’s use the application plugin in our build.gradle:

apply plugin: "java" apply plugin: "application" description = "Gradle Command Line Arguments examples" // previous declarations ext.javaMainClass = "com.baeldung.cmd.MainClass" application

Now, let’s take a look at our main class:

Next, let’s run it with some arguments:

$ ./gradlew :cmd-line-args:run --args="lorem ipsum dolor" > Task :cmd-line-args:run Gradle command line arguments example Got argument [lorem] Got argument [ipsum] Got argument [dolor]

Here, we don’t use properties to pass arguments. Instead, we pass the –args flag and the corresponding inputs there.

This is a nice wrapper provided by the application plugin. However, this is only available from Gradle 4.9 onward.

Let’s see what this would look like using a JavaExec task.

First, we need to define it in our build.gradle:

ext.javaMainClass = "com.baeldung.cmd.MainClass" if (project.hasProperty("args")) < ext.cmdargs = project.getProperty("args") >else < ext.cmdargs = "" >task cmdLineJavaExec(type: JavaExec)

Let’s take a closer look at what we did. We first read the arguments from a project property.

Since this contains all the arguments as one string, we then use the split method to obtain an array of arguments.

Next, we pass this array to the args property of our JavaExec task.

Let’s see what happens when we run this task, passing project properties with the -P option:

$ ./gradlew cmdLineJavaExec -Pargs="lorem ipsum dolor" > Task :cmd-line-args:cmdLineJavaExec Gradle command line arguments example Got argument [lorem] Got argument [ipsum] Got argument [dolor] 

3.2. Passing Arguments to Other Applications

In some cases, we might want to pass some arguments to a third-party application from Gradle.

Luckily, we can use the more generic Exec task to do so:

if (project.hasProperty("args")) < ext.cmdargs = project.getProperty("args") >else < ext.cmdargs = "ls" >task cmdLineExec(type: Exec)

Here, we use the commandLine property of the task to pass the executable along with any arguments. Again, we split the input based on spaces.

Let’s see how to run this for the ls command:

$ ./gradlew cmdLineExec -Pargs="ls -ll" > Task :cmd-line-args:cmdLineExec total 4 drwxr-xr-x 1 user 1049089 0 Sep 1 17:59 bin drwxr-xr-x 1 user 1049089 0 Sep 1 18:30 build -rw-r--r-- 1 user 1049089 1016 Sep 3 15:32 build.gradle drwxr-xr-x 1 user 1049089 0 Sep 1 17:52 src

This can be pretty useful if we don’t want to hard-code the executable in the task.

4. Conclusion

In this quick tutorial, we saw how to pass input arguments from Gradle.

First, we explained the types of properties we can use. Although we can use system properties to pass input arguments, we should prefer project properties instead.

Then, we explored different approaches for passing command-line arguments to Java or external applications.

As usual, the complete code can be found over on GitHub.

Источник

Build Environment

Gradle provides multiple mechanisms for configuring behavior of Gradle itself and specific projects. The following is a reference for using these mechanisms.

When configuring Gradle behavior you can use these methods, listed in order of highest to lowest precedence (first one wins):

• Command-line flags such as —build-cache . These have precedence over properties and environment variables.
• System properties such as systemProp.http.proxyHost=somehost.org stored in a gradle.properties file in a root project directory.
• Gradle properties such as org.gradle.caching=true that are typically stored in a gradle.properties file in a project directory or in the GRADLE_USER_HOME .
• Environment variables such as GRADLE_OPTS sourced by the environment that executes Gradle.

Aside from configuring Gradle behavior you can configure the build using the same mechanisms and reading the environment from the build logic.

Gradle properties

Gradle provides several options that make it easy to configure the Java process that will be used to execute your build. While it’s possible to configure these in your local environment via GRADLE_OPTS or JAVA_OPTS , it is useful to be able to store certain settings like JVM memory configuration and Java home location in version control so that an entire team can work with a consistent environment. To do so, place these settings into a gradle.properties file committed to your version control system.

The final configuration taken into account by Gradle is a combination of all Gradle properties set on the command line and your gradle.properties files. If an option is configured in multiple locations, the first one found in any of these locations wins:

• command line, as set using -D .
• gradle.properties in GRADLE_USER_HOME directory.
• gradle.properties in the project’s directory, then its parent project’s directory up to the build’s root directory.
• gradle.properties in Gradle installation directory.

Note that the location of the Gradle User Home may have been changed beforehand via the -Dgradle.user.home system property passed on the command line.

The following properties can be used to configure the Gradle build environment:

When set to true, Gradle will reuse task outputs from any previous build, when possible, resulting in much faster builds. Learn more about using the build cache. By default, the build cache is not enabled.

When set to true, individual input property hashes and the build cache key for each task are logged on the console. Learn more about task output caching. Default is false .

Enables configuration caching. Gradle will try to reuse the build configuration from previous builds. Default is false .

Configures how the configuration cache handles problems. Set to warn to report problems without failing the build. Set to fail to report problems and fail the build if there are any problems. Default is fail .

org.gradle.configuration-cache.max-problems=(# of problems)

Configures the maximum number of configuration cache problems allowed as warnings until Gradle fails the build. Default is 512 .

Enables incubating configuration on demand, where Gradle will attempt to configure only necessary projects. Default is false .

Customize console output coloring or verbosity. Default depends on how Gradle is invoked. See command-line logging for additional details.

org.gradle.continuous.quietperiod=(# of quiet period millis)

When using continuous build, Gradle will wait for the quiet period to pass before triggering another build. Any additional changes within this quiet period restart waiting for the quiet period. Default is 250 milliseconds.

When set to true the Gradle Daemon is used to run the build. Default is true , builds will be run using the daemon.

org.gradle.daemon.idletimeout=(# of idle millis)

Gradle Daemon will terminate itself after specified number of idle milliseconds. Default is 10800000 (3 hours).

When set to true , Gradle will run the build with remote debugging enabled, listening on port 5005. Note that this is the equivalent of adding -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005 to the JVM command line and will suspend the virtual machine until a debugger is attached. Default is false .

Specifies the host address to listen on or connect to when debug is enabled. In the server mode on Java 9 and above, passing * for the host will make the server listen on all network interfaces. By default, no host address is passed to JDWP, so on Java 9 and above, the loopback address is used, while earlier versions listen on all interfaces.

Specifies the port number to listen on when debug is enabled. Default is 5005 .

If set to true and debugging is enabled, Gradle will run the build with the socket-attach mode of the debugger. Otherwise, the socket-listen mode is used. Default is true .

When set to true and debugging is enabled, the JVM running Gradle will suspend until a debugger is attached. Default is true .

org.gradle.java.home=(path to JDK home)

Specifies the Java home for the Gradle build process. The value can be set to either a jdk or jre location, however, depending on what your build does, using a JDK is safer. This does not affect the version of Java used to launch the Gradle client VM (see Environment variables). A reasonable default is derived from your environment ( JAVA_HOME or the path to java ) if the setting is unspecified.

Specifies the JVM arguments used for the Gradle Daemon. The setting is particularly useful for configuring JVM memory settings for build performance. This does not affect the JVM settings for the Gradle client VM. The default is -Xmx512m «-XX:MaxMetaspaceSize=384m» .

When set to quiet, warn, lifecycle, info, or debug, Gradle will use this log level. The values are not case sensitive. See Choosing a log level. The lifecycle level is the default.

Specifies whether stacktraces should be displayed as part of the build result upon an exception. See also the —stacktrace command-line option. When set to internal , a stacktrace is present in the output only in case of internal exceptions. When set to all or full , a stacktrace is present in the output for all exceptions and build failures. Using full doesn’t truncate the stacktrace, which leads to a much more verbose output. Default is internal .

When configured, Gradle will fork up to org.gradle.workers.max JVMs to execute projects in parallel. To learn more about parallel task execution, see the section on Gradle build performance. Default is false .

Specifies the scheduling priority for the Gradle daemon and all processes launched by it. See also performance command-line options. Default is normal .

Configures verbose logging when watching the file system. Default is false .

Toggles watching the file system. When enabled Gradle re-uses information it collects about the file system between builds. Enabled by default on operating systems where Gradle supports this feature.

When set to all , summary or none , Gradle will use different warning type display. See Command-line logging options for details. Default is summary .

Controls whether Gradle should print a welcome message. If set to never then the welcome message will be suppressed. If set to once then the message is printed once for each new version of Gradle. Default is once .

org.gradle.workers.max=(max # of worker processes)

When configured, Gradle will use a maximum of the given number of workers. See also performance command-line options. Default is number of CPU processors.

The following examples demonstrate how to use Gradle properties.

gradlePropertiesProp=gradlePropertiesValue gradleProperties.with.dots=gradlePropertiesDottedValue

Источник