Skip to main content

The Great Gradle Cheat Sheet

This article intend to work as a gradle in nutshell. I will try to keep it as concise as possible while trying to touch as many frequently used gradle operations as possible.

Task Chain

task compile {
    doLast {
        println 'compiling source'
    }
}

task compileTest(dependsOn: compile) {
    doLast {
        println 'compiling unit tests'
    }
}

# gradle compileTest
Above command will execute "compile" task first and then compileTest.

Excluding Tasks with -x

#gradle compileTest -x compile

Abbreviating task names by camel initials

#gradle compileTest
#gradle ct  


Running subproject

#gradle -p subdir compileTest

Listing all tasks

#gradle -q tasks

List project dependencies

#gradle -q dependencies

Listing build script dependencies

gradle buildEnvironment

List project properties

gradle -q properties

Profiling build operation
gradle build --profile

Above command generates nice report about time taken in each steps as shown below.




Pre-check the order of tasks

Use -m flag to mock run (dry run) the task. It will list out all the tasks in the order of execution.
gradle -m build

Using gradlew instead of gradle

If you feel installing gradle and maintaing same version across all users is a burden, you can use gradle wrapper. Gradle wrapper is the gradle script which can be kept at the root of the project and checkin to your code repository so that all users have it. Once it is done, all gradle commands can be run as ./gradlew instead of gradle. Following gradle task installs the gradle wrapper.

gradle wrapper --gradle-version 2.0

Dependency resolution

Dependencies can be declared by following dependency configuration
dependencies {
    compile 'org.hibernate:hibernate-core:3.6.7.Final'
}

The syntax is compile 'group:name:version'

Repository declaration

We need to tell gradle the source from where dependencies can be downloaded. It is done via following configuration:
repositories {
    mavenCentral(),
    jcenter()
}

Variables for gradle script

Variables declared in the gradle.properties file gets available to be used in gradle file. If variable has prefix "sytemProps", those get available as system variable. System variable are accessed as System.properties['variable_name']

User-specific variables can be set in gradle.properties at the location <User-Home>/.gradle/gradle.properties  User-specific variables gets precedence over project specific gradle.properties
to be continued...

Comments

  1. Great Article
    Cloud Computing Projects


    Networking Projects

    Final Year Projects for CSE


    JavaScript Training in Chennai

    JavaScript Training in Chennai

    The Angular Training covers a wide range of topics including Components, Angular Directives, Angular Services, Pipes, security fundamentals, Routing, and Angular programmability. The new Angular TRaining will lay the foundation you need to specialise in Single Page Application developer. Angular Training

    ReplyDelete

Post a Comment

Popular posts from this blog

Auto Scaling DynamoDB

Those of you who have worked with the DynamoDB long enough, will be aware of the tricky scaling policies of DynamoDB. It allows user to explicitly set requests per second (units per second, but for simplicity we will just say request per second). User can do so for read as well as write operations. Anytime user can increase or decrease the provision capacity from DynamoDB web console and it will reflect immediately. Sounds all good....... Or not? What if you set provisioned capacity to 50 req per second but load on the server crosses 100 req per second? Requests gets throttled!! Mostly times out. What's worse? This can cause requests getting queued up in your web server. Which can potentially bring your entire server down. What if you set provisioned capacity to 1000 req per second but load on the server is only 100 req per second through out the day? You lose your hard earned money for remaining 900 req per second. What if you set it to 1000 req per sec and then realis

StackDriver Integration with AWS Elastic Beanstalk - Part 2

Eb Extension Config Our goal is to create a configuration such that, it can run on any elastic beanstalk instance. It should send production and non-production logs to two seperate Stackdriver projects. Adding monitoring for new log file should include minimal changes at best. If you have used Elastic Beanstalk before, probably you will be familiar with eb-extensions scripts. These are the set of commands those run everytime application is deployed on the EB. Step 1: Create folder .ebextension in your WEB-ROOT directory.  EB by default looks for ".config" files under .ebextension directory and executes on app-deployment. Add sub-directory called "stackdriver" under .ebextension directory that you just created. Step 2: Add google-fluentd.conf file in stackdriver directory.  Fluent-d agent runs on this configuration. This file tells the fluentd where to look for log files. Following sample file configures fluentd to check for app.log and billing.log files.