Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

''Refined'' Gradle

DZone's Guide to

''Refined'' Gradle

Check out this set of Gradle scripts designed to make your life easier with your favorite build automation tool.

· Java Zone
Free Resource

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

Maven and Gradle are the most widespread build automation tools. I use both of them in my projects.

Gradle is based on Groovy and is more flexible, than Maven. Thus, every developer can customize Gradle scripts to meet some requirements.

I decided to define a set of conventions to use Gradle. My goal was to make Gradle scripts for each project more unified, concise, manageable, and readable. In this article, I would like to share the results.

The GitHub repo with the template helper scripts and sample scripts is here.

I have three types of dependencies in the projects:

  • Artifacts from remote repositories

  • Modules that are shared among several projects

  • Modules that are used in one project only

Accordingly, I use a separate Gradle script with helper closures and methods for each type of dependency.

These scripts contain code or serve as a facade for other scripts. You can find samples of these scripts in my GitHub repo here. In fact, the helper scripts are Gradle Script plugins.

Eventually, project Gradle scripts look the following.

Root project settings.gradle:

ext.commonDir = '../Common'
apply from: '../vlfsoftCommon.gradle'

// AND, if there are many internal sub-projects in the project with dependencies of each other
apply from: 'projectCommon.gradle'

includeCommonSdAnnotations()
includeCommonUtil()

//include ':vlfsoft.refined.gradle.app'
//include ':vlfsoft.refined.gradle.module'

// OR, if there are many internal sub-projects in the project with dependencies of each other

includeProjectRefinedGradleApp()
includeProjectRefinedGradleModule()


Root project build.gradle:

buildscript {

    ext.commonDir = '../Common'
    apply from: '../common.gradle'

    repositories buildscriptCommonRepo
    dependencies buildscriptKotlinPluginDep

    apply from: '../vlfsoftCommon.gradle'

    // AND, if there are many internal sub-projects in the project with dependencies of each other
    apply from: 'projectCommon.gradle'

}

allprojects allprojectsCommon
allprojects allprojectsKotlin

task wrapper(type: Wrapper) {
    gradleVersion = customGradleVersion
}


Sub-project build.gradle:

apply plugin: 'application'

dependencies kotlinStdlibDep

dependencies commonSdAnnotationsDep
dependencies commonUtilDep

/*
dependencies {
    compile project(':vlfsoft.refined.gradle.module')
}
*/

// OR, if there are many internal sub-projects in the project with dependencies of each other
dependencies projectRefinedGradleModuleDep

apply from: '../../jarProperties.gradle'
// https://stackoverflow.com/questions/26469365/building-a-self-executable-jar-with-gradle-and-kotlin
mainClassName = 'vlfsoft.refined.gradle.ApplicationKt'
jarAppProp()


To avoid "version hell," I use a single shared Gradle script with versions of the artifacts.

versions.gradle:

//--BEG: gradle
    ext.customGradleVersion = '4.3.1'
//--END: gradle

...

//--BEG: html parsers

        // https://mvnrepository.com/artifact/org.jsoup/jsoup
        ext.jsoupVersion = '1.10.3'

//--END: html parsers

...


Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat

Topics:
gradle ,maven ,build automation ,java ,tutorial

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}