Enterprise Java

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

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
// 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.
 

Do you want to know how to develop your skillset to become a Java Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
I agree to the Terms and Privacy Policy
Subscribe
Notify of
guest


This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Back to top button