I have a task of type JavaExec that does a lot of complicated steps in order to compile & run the application. This task is generated by a plugin outside of my control.
I want to create another task that "extends" this task, adding an extra dependency configuration. This configuration stores some dependencies that should only be included for this specific task.
Is there an easy way for me to create such a task, or do I have to copy over all configuration properties (which may change at any time) manually?
Related
I usually define tasks in Gradle (using Groovy) like tasks.withType(Type); e.g.: tasks.withType(JavaCompile), tasks.withType(Test), etc.
Now, I want to do the same with some provided Spring Boot tasks, namely: bootRun and bootStartScripts, but Gradle cannot find it.
I know it's silly and I could get away just by using bootRun and bootStartScripts, but I would like to understand why those cannot be configured/defined in such way.
I guess with define you mean configure, because withType can only be used to configure existing tasks. It takes a task type (a class) and a closure that can be used to configure all available tasks of that type. This needs to be considered, because a project may contain multiple tasks of the same type that should actually do completely different things. Whether to configure all those tasks or just a specific one is important!
To pass the task type to the method withType you need to know the name of the class implementing the task type. This name is not necessarily related to the name(s) of the actual task(s). For the tasks test and compileJava of the Gradle Java Plugin those classes are org.gradle.api.tasks.testing.Test and org.gradle.api.tasks.compile.JavaCompile. Since those classes are provided by Gradle, they are automatically imported and can be referenced via their simple names Test and JavaCompile. But the Spring Boot Plugin is a third-party plugin, so the classes need to be referenced by their full names.
The task bootStartScripts from your question is of type CreateStartScript, that is provided by Gradle. Therefore it can be configured like this:
tasks.withType(CreateStartScripts) {
// configure
}
The task bootRun is of type org.springframework.boot.gradle.tasks.run.BootRun, that is provided by the Spring Boot Plugin. So you need to specify the full name:
tasks.withType(org.springframework.boot.gradle.tasks.run.BootRun) {
// configure
}
I am new to Gradle. I have written a JavaCompile task. So, when I didn't specify the classpath in the task it is throwing me an error. In maven, we don't specify the classpath it automatically takes the default location of the dependencies and takes them during compilation. Is it a must to specify the classpath in Gradle?
Yes, the task needs a classpath set via a property available during the configuration phase.
It isn't common in my experience to declare JavaCompile tasks directly, and when you do it usually means some sort of the special or custom build. In this case you will want full control over the compiler options.
A common motif is for the classpath to be set in terms of a specific configuration:
classpath = configurations.compile
This is similar in practice to the implicit Maven classpath taken from the dependencies. However, since Gradle config is composed of blocks of Groovy (or whatever) and not contextual XML, you have to tell it from what configuration you want to take the classpath.
Gradle java plugin offers a classes task, which describes
"Assembles the production classes and resources directories."
what does it mean? what exactly it does.
One more task is check, it says
All verification tasks in the project, including test.
what does this means? what are the other verification tasks apart from test?
Assembles the production classes and resources directories
It assembles under your build directory both class-files and resources, in the classes and resources folders accordingly. It depend on the comlipe and processResources tasks and make both of them run. That mean, that you can get the content, in your build folder, which later will be added into some archive (jar, war or ear) if you'll call some task to assemble it.
what are the other verification tasks apart from test?
You can add some plugins to your build script, for example checkstyle or findbugs. This plugins add some additional verifications, such a static analysis of source code and etc. All this actions will be performed while check is executed.
I often meet in Gradle documentation these concepts. What is the difference between them?
From what I know custom task is class that encapsulates some logic, but what is enhanced task and what is the difference between them?
A simple task in Gradle is an instance of DefaultTask and does not do anything out of the box. To make it do something you have to add code to the task definition in your build script.
An enhanced task is an instance of a different class (for example a Copy task is an instance of Copy) and has some behaviour out of the box. You just need to configure that behaviour in your build script (eg tell it where to copy from and to)
A custom task is an enhanced task that is an instance of a class you wrote yourself.
An enhanced task is defined in the Gradle manual as:
Gradle supports enhanced tasks, that is, tasks which have their own properties and methods. This is really different to what you are used to with Ant targets. Such enhanced tasks are either provided by you or are provided by Gradle.
It also says:
Gradle supports two types of task. One such type is the simple task, where you define the task with an action closure. We have seen these in Chapter 6, Build Script Basics. For this type of task, the action closure determines the behaviour of the task. This type of task is good for implementing one-off tasks in your build script.
The other type of task is the enhanced task, where the behaviour is built into the task, and the task provides some properties which you can use to configure the behaviour. We have seen these in Chapter 15, More about Tasks. Most Gradle plugins use enhanced tasks. With enhanced tasks, you don't need to implement the task behaviour as you do with simple tasks. You simply declare the task and configure the task using its properties. In this way, enhanced tasks let you reuse a piece of behaviour in many different places, possibly across different builds.
The behaviour and properties of an enhanced task is defined by the task's class. When you declare an enhanced task, you specify the type, or class of the task.
As part of writing a Gradle plugin for Flyway, we stumbled upon a problem when dealing with Java migrations.
What is the best way to provide a Gradle plugin access on its classpath to the compiled classes of the project so that it can load and execute them?
So the situation is that we have a plugin that adds a task that wants to execute code contained in the project that the plugin is applied to. In this case, the task (class) should have an input property of type Iterable<File> that gets configured (by the plugin) with the class path of the code to be executed (e.g. sourceSets.main.runtimeClasspath). The task can then choose between the following ways to execute the code:
The task uses project.javaexec {} to execute the code in a separate JVM. If the code isn't directly executable, the task may need to inject some bootstrap code onto the javaexec class path. A potential alternative to using project.javaexec is to use a JavaExec task in the first place.
The task creates a new class loader, populates it with the class path, loads and instantiates the classes that serve as the entry point(s) to the API, and makes use of them as appropriate. If the task is written in Groovy, it can leverage duck typing, and no reflective code will be necessary beyond creating the entry points.