Gradle TipsContributing to Gradle tipsTip 1 Use Gradle WrapperTip 2 View Dependency GraphTip 3 Build a single PRojectTip 4 Exclude tasksTip 5 Profile your buildTip 6 Perform dry runTip 7 Install project jars into local Maven repositoryTip 8 View Gradle tasksTip 9 Use Gradle daemonTip 10 Parallelize the buildTip 11 Customize Gradle tasksTip 12 Provide JVM arguments to Gradle daemonTip 13 Run in offline modeTip 14 Enable configure on demandTip 15 Refresh Gradle dependency cacheTip 16 Define a local jar dependencyTip 17 Define all jars in a local directory as dependencyTip 18 Build project and all project it depends onTip 19 Build project and all its dependentsTip 20 Provide default tasks to your build scriptTip 21 Create checksum for a fileTip 22 Using different name for build fileTip 23 Using different names for build script in multi-project Gradle projectTip 24 Using Gradle guiTip 25 Create untar taskTip 26 Fail configuration on version conflictTip 27 Using provided scope in GradleTip 28 Set java compile encoding explicitlyTip 29 Disable transitive dependencies resolutionTip 30 Viewing Gradle versionTip 31 Disable a taskTip 32 Init a Gradle projectTip 33 Sign artifactsTip 34 Running tests in parallelTip 35 Set memory for testsTip 36 Using short names for tasksTip 37 Learn about a Gradle taskTip 38 Run gradle in debug modeTip 39 Continue task execution after task failureTip 40 Convert Maven project to GradleTip 41 Force Gradle to rerun tasks even if they are UP-TO-DATETip 42 Use exact version numbers in dependenciesTip 43 Enable continuous buildTip 45 Run a single test caseTip 45 Generate source and javadoc jar46 accessing environment variable in build script47 Configure test loggingTip 48 Show Standard Output and Error Stream during tests executionTip 49 Storing credentialsTip 50 Debug a Java executable application
Over last year or so I have started using Gradle as my primary build tool for JVM based projects. Before using Gradle I was an Apache Maven user. Gradle takes best from both Apache Maven and Apache Ant providing you best of both worlds. Gradle borrows flexibility from Ant and convention over configuration, dependency management and plugins from Maven. Gradle treats task as first class citizen just like Ant.
A Gradle build has three distinct phases - initialization, configuration, and execution. The initialization phase determine which all projects will take part in the build process and create a Project instance for each of the project. During configuration phase, it execute build scripts of all the project that are taking part in build process. Finally, during the execution phase all the tasks configured during the configuration phase are executed.
In this document, I will list down tips that I have learnt over last year or so.
@(技术Inbox)[gradle]
Please contribute if you see an error or something that could be better! Raise an issue or send me a pull request to improve. Contributions of all kinds, including corrections, additions, improvements, and translations, are welcome!
One of the Gradle features that impressed me a lot when I was starting with Gradle was support for wrapper scripts. Gradle wrapper makes your project self contained and independent of build tool installation. It lets you run Gradle builds without a previously installed Gradle distribution in a zero configuration manner. This will ensure everyone use same version of the build tool.
To create Gradle wrapper scripts for your Grade project you can run following command.
$ gradle wrapper --gradle-version 2.14.1To run the above command you will need Gradle installed on your machine. If you are on Mac, then you can use brew install gradle
.
This will generate few files in your project – gradlew
, gradlew.bat
, gradle/wrapper/gradle-wrapper.jar
, and gradle/wrapper/gradle-wrapper.properties
. Now instead of running gradle
you should run gradlew
.
Make sure to unignore gradle-wrapper.jar
in your version control ignone file. By default, version control ignore files ignore jar files.
At any point in time, if you wish to upgrade the Gradle version just regenerate the Gradle wrapper scripts passing it the Gradle version you want to use. Let’s suppose we want to upgrade to Gradle 3.0-milestone-2
run the command again as shown below.
Also, it is a good idea to set an alias for ./gradlew
.
To view a dependency graph for your project you can run the following command.
$ gradle dependenciesGradle supports both single and multi-project builds. Let’s suppose our multi-project structure looks like as shown below.
app api model rest core web itestsTo build the rest
project we will run the following command.
To exclude a task you use -x
option. Let’s suppose we want to skip tests then we can use following command
Gradle has in-built support for profiling. If you are facing performance issues, you should use the --profile
option to generate profile report. The report displays time taken by different tasks. Let’s suppose we want to profile the build task then we can run the following command.
This will generate report in the build/reports/profile
directory.
There are times when you wish to see all the tasks that will be executed during the build but don’t want to execute them. For this scenario Gradle provides --dry-run
option.
The above does not list all the tasks. To view all the tasks you have to pass --all
flag.
One of the easiest way to speed your Gradle build is to use Gradle daemon to run your build. Gradle daemon is a long-lived background process that performs bootstrapping only once during its lifetime. Gradle daemon is not enabled by default. To use Gradle daemon, you can use --daemon
flag to your build command.
It will enabled by default in 3.0.
Passing the --daemon
flag each time is cumbersome so you can enable it on your developer machine by adding this flag in the ~/.gradle/gradle.properties
file.
Open your ~/.gradle/gradle.properties
and add the following line.
You can customize any Gradle tasks by overriding its doFirst
and doLast
life cycle methods. Let’s suppose we want add print statements before and after executing tests we can do that by following.
You can specify JVM arguments to Gradle daemon by entering a line in ~/.gradle/gradle.properties
as shown below.
Configuration on demand is an incubation feature of Gradle, so it’s not enabled by default yet.
$ gradle clean build --configure-on-demandIf you want to make this a default option, then you can provide this option globally by adding a line to ~/.gradle/gradle.properties
You can also delete the cached files under ~/.gradle/caches
. Next time, when you will run the build it will download all the dependencies and populate your cache.
Let’s suppose you have a lib
directory that contains jar file that you need to use in your Gradle project.
This can also be done by following.
repositories { flatDir { dirs 'libs' }}dependencies { compile name: 'myjar'}If you need to add all the libraries in a directory then you can do the following:
dependencies { compile fileTree(dir: 'libs', include: ['*.jar'])}It is a good practice to define default tasks for your project so that a first time user of your project can easily get started. In your Gradle script, define defaultTasks
variable passing it the tasks it should execute.
Now, if a user will run gradle
command default tasks will be executed.
By default build file has build.gradle
as its name. You can use a different name by doing following in the settings.gradle
file.
Now, rename your build file build.gradle
to gradle-tips.gradle
By convention, we use build.gradle
as the name of the Gradle build script. When you are working with a multi-project Gradle project then it make sense to use different names for build scripts. Let’s suppose our multi module project looks like this:
By default, all of these sub projects will have build.gradle
as their Gradle build file. We can change that by overriding that in settings.gradle
Now, you can use build.gradle for root project. Sub projects will have api.gradle
, core.gradle
, web.gradle
, and itests.gradle
as their build definition files.
You can use Gradle gui by launching it via command-line as shown below.
$ gradle --guiThis will open the Gradle gui as shown below.
In your build script, define a configuration block as shown below.
configurations { compile.resolutionStrategy.failOnVersionConflict()}You can use maven like provided
scope in gradle 2.12+ by using ‘compileOnly’ scope.
In your build.gradle
add the following line.
Turn transitive dependencies off for a whole configuration:
configurations { compile.transitive = false}You can view Gradle version
$ gradle -v------------------------------------------------------------Gradle 2.14.1------------------------------------------------------------Build time: 2016-07-18 06:38:37 UTCRevision: d9e2113d9fb05a5caabba61798bdb8dfdca83719Groovy: 2.4.4Ant: Apache Ant(TM) version 1.9.6 compiled on June 29 2015JVM: 1.8.0_60 (Oracle Corporation 25.60-b23)OS: Mac OS X 10.10.5 x86_64You can view the Gradle version that your current build is running by using GradleVersion.current()
. You can create a task that does the work.
When you will run it you will see the following:
$ gradle gradleVersion:gradleVersionYou are using [Gradle 2.14.1]BUILD SUCCESSFULTotal time: 0.667 secsIf you want to disable test task then you can disable it as shown below.
test.enabled = falseTo create Java Gradle project that uses testng testing framework you can use the following command.
$ gradle init --type java-library --test-framework testngIf you want to use JUnit, then don’t specify --test-framework
You can also create groovy and scala projects as well.
$ gradle init --type scala-library$ gradle init --type groovy-libraryIf you only want to sign releases not snapshots then you can do following
apply plugin: 'signing'signing { required { !version.endsWith("SNAPSHOT”) }}If you have a task buildServerDistribution
then you can call it as shown below.
You have to make sure it is unique among all tasks. If there is another task buildSafeDistribution
then you have specify
Go to your Maven project and run the following command.
$ gradle init --type pomWhen you are declaring dependencies don’t use + in your dependencies, rather use exact version numbers. This will make your build faster and reproducible.
If you wish to continuously run your build then you can use --continuous
flag. It will look for file changes and whenever it detects one it will rerun the command. To enable continuous tests,
There are times when we only when to run a single test case rather than running the full test suite. This can be accomplished by following command.
$ gradle test --tests tips.CalculatorTestTo run only a single test case of tips.CalculatorTest
you can do following.
You can also use regex to specify multiple tests
$ gradle test --tests "tips.Calculator*Test"You can also use --tests
flag multiple times.
To run a single test in a submodule you can do following
$ gradle api:test --tests app.api.PingResourceTestYou can access environment variables in couple of ways
println(System.getenv("HOME"))println("$System.env.HOME")By default Gradle will only log test failures on console. This at times limits the visibility of which all tests have ran. Gradle allows you to configure it using the testLogging property. To log all the events, you can do following. For more information read this.
test { testLogging { events "passed", "skipped", "failed" }}Now, when you will run the ./gradlew clean build
you will see passed tests as well.
One thing to keep in mind is that gradle test
command executes the test only when they change. So if you run it second time without any change then no output will be produced. You will see :test UP-TO-DATE
which means no changes were detected. You can force Gradle to run tests each time by using ./gradlew cleanTest test
.
You should not hardcode credentials in your build.gradle
instead you should rely on your user home ~/.gradle/gradle.properties
to store credentials. Let’s suppose you want to use a Maven repository protected by credentials. One way to specify credentials is to hard code them in your build.gradle as shown below.
The better way is to change your personal ~/.gradle/gradle.properties
Now, refer this in the build.gradle
If your application is packaged as an executable jar that you can run via Gradle then you can debug it by passing --debug-jvm
option. Spring Boot applications are run as an executable jar. You can use gradle bootRun
to run the application. To debug the app at port 5005 you can start app in debug mode.
You can follow me on twitter at https://twitter.com/shekhargulati or email me at shekhargulati84@Gmail.com. Also, you can read my blogs at http://shekhargulati.com/
.
新闻热点
疑难解答