JavaExec
Similar to Exec , but starts a JVM with the given classpath and application class.
plugins < id 'java' > task runApp(type: JavaExec) < classpath = sourceSets.main.runtimeClasspath mainClass = 'package.Main' // arguments to pass to the application args 'appArg1' > // Using and creating an Executable Jar jar < manifest < attributes('Main-Class': 'package.Main') > > task runExecutableJar(type: JavaExec) < // Executable jars can have only _one_ jar on the classpath. classpath = files(tasks.jar) // 'main' does not need to be specified // arguments to pass to the application args 'appArg1' >
The process can be started in debug mode (see JavaExec.getDebug() ) in an ad-hoc manner by supplying the `—debug-jvm` switch when invoking the build.
gradle someJavaExecTask --debug-jvm
Also, debug configuration can be explicitly set in JavaExec.debugOptions(org.gradle.api.Action) :
task runApp(type: JavaExec) < . debugOptions < enabled = true port = 5566 server = true suspend = false > > Properties
The full set of arguments to use to launch the JVM for the process. This includes arguments to define system properties, the minimum/maximum heap size, and the bootstrap classpath.
The arguments passed to the main class to be executed.
Argument providers for the application.
The bootstrap classpath to use for the process. The default bootstrap classpath for the JVM is used when this classpath is empty.
The classpath for executing the main class.
The full command line, including the executable plus its arguments.
Determines whether debugging is enabled for the test process. When enabled — debug = true — the process is started in a suspended state, listening on port 5005. You should disable parallel test execution when debugging and you will need to reattach the debugger occasionally if you use a non-zero value for Test.getForkEvery() .
The Java Debug Wire Protocol properties for the process. If enabled then the -agentlib:jdwp=. will be appended to the JVM arguments with the configuration from the parameter.
Returns true if assertions are enabled for the process.
The environment variables to use for the process. Defaults to the environment of this process.
The output stream to consume standard error from the process executing the command. Default to System.err .
The name of the executable to use.
The result for the command run by this task. The provider has no value if this task has not been executed yet.
Tells whether a non-zero exit value is ignored, or an exception thrown. Defaults to false .
Configures the java executable to be used to run the tests.
The extra arguments to use to launch the JVM for the process. Does not include system properties and the minimum/maximum heap size.
Command line argument providers for the java process to fork.
Extra JVM arguments to be to use to launch the JVM for the process. Must be used to set a convention for JVM arguments.
The fully qualified name of the Main class to be executed.
The name of the main module to be executed if the application should run as a Java module.
The maximum heap size for the process, if any.
The module path handling for executing the main class.
The standard input stream for the process executing the command. The stream is closed after the process completes. Defaults to an empty stream.
The output stream to consume standard output from the process executing the command. Defaults to System.out .
The system properties which will be used for the process.
The working directory for the process. Defaults to the project directory.
Build Script Basics
This chapter introduces you to the basics of writing Gradle build scripts. It uses toy examples to explain basic functionality of Gradle, which is helpful to get an understanding of the basic concepts. Especially if you move to Gradle from other build tools like Ant and want to understand differences and advantages.
However, to get started with a standard project setup, you don’t even need to go into these concepts in detail. Instead, you can have a quick hands-on introduction, through our step-by-step samples.
Projects, plugins and tasks
Every Gradle build is made up of one or more projects. What a project represents depends on what it is that you are doing with Gradle. For example, a project might represent a library JAR or a web application. It might represent a distribution ZIP assembled from the JARs produced by other projects. A project does not necessarily represent a thing to be built. It might represent a thing to be done, such as deploying your application to staging or production environments. Don’t worry if this seems a little vague for now. Gradle’s build-by-convention support adds a more concrete definition for what a project is.
The work that Gradle can do on a project is defined by one or more tasks. A task represents some atomic piece of work which a build performs. This might be compiling some classes, creating a JAR, generating Javadoc, or publishing some archives to a repository.
Typically, tasks are provided by applying a plugin so that you do not have to define them yourself. Still, to give you an idea of what a task is, we will look at defining some simple tasks in a build with one project in this chapter.
Hello world
You run a Gradle build using the gradle command. The gradle command looks for a file called build.gradle.kts in the current directory. [1] We call this build.gradle.kts file a build script, although strictly speaking it is a build configuration script, as we will see later. The build script defines a project and its tasks.
To try this out, create the following build script named build.gradle.kts .
You run a Gradle build using the gradle command. The gradle command looks for a file called build.gradle in the current directory. [2] We call this build.gradle file a build script, although strictly speaking it is a build configuration script, as we will see later. The build script defines a project and its tasks.
To try this out, create the following build script named build.gradle .
Building Java Applications Sample
This guide demonstrates how to create a Java application with Gradle using gradle init . You can follow the guide step-by-step to create a new project from scratch or download the complete sample project using the links above.
What you’ll build
You’ll generate a Java application that follows Gradle’s conventions.
What you’ll need
- A text editor or IDE — for example IntelliJ IDEA
- A Java Development Kit (JDK), version 8 or higher — for example AdoptOpenJDK
- The latest Gradle distribution
Create a project folder
Gradle comes with a built-in task, called init , that initializes a new Gradle project in an empty folder. The init task uses the (also built-in) wrapper task to create a Gradle wrapper script, gradlew .
The first step is to create a folder for the new project and change directory into it.
Run the init task
From inside the new project directory, run the init task using the following command in a terminal: gradle init . When prompted, select the 2: application project type and 3: Java as implementation language. Next you can choose the DSL for writing buildscripts — 1 : Groovy or 2: Kotlin . For the other questions, press enter to use the default values.
The output will look like this:
$ gradle init Select type of project to generate: 1: basic 2: application 3: library 4: Gradle plugin Enter selection (default: basic) [1..4] 2 Select implementation language: 1: C++ 2: Groovy 3: Java 4: Kotlin 5: Scala 6: Swift Enter selection (default: Java) [1..6] 3 Select build script DSL: 1: Groovy 2: Kotlin Enter selection (default: Groovy) [1..2] 1 Select test framework: 1: JUnit 4 2: TestNG 3: Spock 4: JUnit Jupiter Enter selection (default: JUnit 4) [1..4] Project name (default: demo): Source package (default: demo): BUILD SUCCESSFUL 2 actionable tasks: 2 executed
The init task generates the new project with the following structure:
├── gradle (1) │ └── wrapper │ ├── gradle-wrapper.jar │ └── gradle-wrapper.properties ├── gradlew (2) ├── gradlew.bat (2) ├── settings.gradle.kts (3) └── app ├── build.gradle.kts (4) └── src ├── main │ └── java (5) │ └── demo │ └── App.java └── test └── java (6) └── demo └── AppTest.java├── gradle (1) │ └── wrapper │ ├── gradle-wrapper.jar │ └── gradle-wrapper.properties ├── gradlew (2) ├── gradlew.bat (2) ├── settings.gradle (3) └── app ├── build.gradle (4) └── src ├── main │ └── java (5) │ └── demo │ └── App.java └── test └── java (6) └── demo └── AppTest.java| 1 | Generated folder for wrapper files |
| 2 | Gradle wrapper start scripts |
| 3 | Settings file to define build name and subprojects |
| 4 | Build script of app project |
| 5 | Default Java source folder |
| 6 | Default Java test source folder |
You now have the project setup to build a Java application.
Review the project files
The settings.gradle(.kts) file has two interesting lines:
rootProject.name = "demo" include("app")