Simple Gradle Java Plugin Customization

As I demonstrated in the post A First Look at Building Java with Gradle, Gradle is particularly concise and easy to apply to the basics of building a Java application when one uses the Java plugin and places files and directories where this plugin expects them (convention-based project layout). However, it is not always possible to have a structure (especially in legacy systems) meeting Gradle’s expected conventions. In this post, I look at overriding some of the Gradle Java Plugin’s conventions to allow a simple Gradle build to work with different directory structures.

The code listing that follows contains the Gradle code for a build build.gradle. I included comments in the build code to help explain what each type of customization is doing.

build.gradle

// build.gradle
//
// This simple example of a Gradle build file exists primarily to demonstrate
// approaches to overriding Gradle's default conventions related to use of the
// Java plugin.

// The 'java' plugin must be applied before attempting to access the sourceSets
// and other properties defined by the Java plugin to avoid an error message
// similar to the following: "Could not find method sourceSets() for arguments..."
apply plugin: 'java'

// Redefine where Gradle should expect Java source files (*.java)
sourceSets {
    main {
        java {
            srcDirs 'java'
        }
        resources {
            srcDir 'resources'
        }
    }
}

// Redefine where .class files are written
sourceSets.main.output.classesDir = file("dist/classes")

// Redefine where 'jar' task should place generated JAR file.
jar {
   destinationDir = file('dist/jar')
}

// Fully qualified directory/JAR for Guava Release 16 JAR file:
//    C:\\guava16\\guava-16.0-rc1.jar
repositories { 
  flatDir{
    dirs 'C:\\guava16'
  } 
}

dependencies {
   compile 'guava:guava:16.0-rc1'
}

defaultTasks 'clean', 'jar'

The Gradle build file shown above first applies the Java plugin. It then overrides the Gradle conventional locations for Java source files (highest level directory where subdirectories represent packages and files have .jar extensions), changing this directory from the default of src/main/java to simply java. Similarly, the default src/main/resources location for production resources is changed to simply resources.

The build file shown above then changes where the *.class files (with appropriate subdirectories representing their package structure) are placed by specifying that sourceSets.main.output.classesDir is now dist/classes (build/classes/main is conventional default). Similarly, the jar task’s destinationDir is overridden to point to dist/jar (build/libs is convention) and this is where the JAR file generated by the jar task is written.

The final customization shown in the simple Gradle build script shown above is the specification of “repositories” and “dependencies” to make Guava Release 16 JAR available to my application (which happens to depend on Guava Release 16). Gradle provides sophisticated support for use of Maven or Ivy repositories including special syntax for Maven Central, but this particular example gets the Guava Release 16 JAR from my local file system (C:\guava16). The dependency itself is expressed with “guava:guava:16.0-rc1″ because the JAR in that specified repository directory is called “guava-16.0-rc1.jar.”

To make my testing of these customizations easier, I explicitly specified defaultTasks as clean and jar so that all I needed to do was type gradle on the command line as long as I was in the same directory as the build.gradle file shown above and as long as there was a “java” subdirectory at that level with the .java source files in their appropriate package-based directories.

Gradle’s builds are most concise and easiest to write and read when Gradle’s conventions are followed. However, it is not terribly difficult to override these conventions and specify customized configuration to match legacy systems.
 

Related Whitepaper:

Functional Programming in Java: Harnessing the Power of Java 8 Lambda Expressions

Get ready to program in a whole new way!

Functional Programming in Java will help you quickly get on top of the new, essential Java 8 language features and the functional style that will change and improve your code. This short, targeted book will help you make the paradigm shift from the old imperative way to a less error-prone, more elegant, and concise coding style that’s also a breeze to parallelize. You’ll explore the syntax and semantics of lambda expressions, method and constructor references, and functional interfaces. You’ll design and write applications better using the new standards in Java 8 and the JDK.

Get it Now!  

Leave a Reply


nine − 5 =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books