We have already discussed that the Java plugin adds tasks and source sets to our Gradle project; however, we also get a lot of new properties that we can use. Custom properties of a plugin are set in a Convention object of the org.gradle.api.plugins.Convention type. A Convention object is used by a plugin to expose properties and methods that we can use in our project. The Convention object of the plugin is added to the convention property of a project. The convention property of a Gradle project is a container for all the Convention objects from the plugins.

We can access the properties from the plugin's Convention object directly as project properties or we can specify the complete path to the Convention object of the plugin in order to get to a property or invoke a method.

For example, the sourceSets property is a property of the Convention object of the Java plugin. With the following task, showConvention, we see the different ways that we have in order to access this property:

task showConvention << { 
    println sourceSets.main.name 
    println project.sourceSets.main.name 
    println project.convention.plugins.java.sourceSets.main.name 
} 

To see all the properties available to us, we must invoke the properties task from the command line. The following output shows a part of the output from the properties task:

$ gradle properties
:properties
...
targetCompatibility: 1.8
tasks: [task ':buildDependents', task ':buildNeeded', task ':check', task ':classes', task ':compileJava', task ':compileTestJava', task ':jar', task ':javadoc', task ':processResources', task ':processTestResources', task ':properties', task ':test', task ':testClasses']
test: task ':test'
testClasses: task ':testClasses'
testReportDir: /gradle-book/Chapter4/Code_Files/props/build/reports/tests
testReportDirName: tests
testResultsDir: /gradle-book/Chapter4/Code_Files/props/build/test-results
testResultsDirName: test-results
version: unspecified
...

If we look through the list, we see a lot of properties that we can use to redefine the directories where output files of the compile or test tasks are stored. The following table shows the directory properties:

The Java plugin also adds other properties to our project. These properties can be used to set the source and target compatibility of the Java version for compiling the Java source files or set the base filename for the generated JAR files.

The following table shows the convention properties of the Java plugin:

In our example project, we already saw that the generated JAR file was named after the project name; but with the archivesBaseName property, we can change that. We can also change the source compatibility to Java 6 for our project. Finally, we can also change the manifest that is used for the generated JAR file. The following build file reflects all the changes:

apply plugin: 'java' 
 
archivesBaseName = 'gradle-sample' 
version = '1.0' 
 
sourceCompatibility = JavaVersion.VERSION_1_8 // Or '1.8' or 8 
 
jar { 
    manifest { 
      attributes( 
        'Implementation-Version' : version, 
        'Implementation-Title' : 'Gradle Sample' 
      ) 
    } 
} 
... 

Now if we invoke the assemble task to create our JAR file and look into the build/libs directory, we can see that the JAR file is now named gradle-sample-1.0.jar:

$ gradle assemble
:compileApiJava
:processApiResources UP-TO-DATE
:apiClasses
:compileJava
:processResources
:classes
:jar
:assemble
BUILD SUCCESSFUL
Total time: 0.657 secs
$ ls build/libs
gradle-sample-1.0.jar

To see the contents of the generated manifest file, we will first extract the file from the JAR file and then look at the contents:

$ cd build/libs
$ jar xvf gradle-sample-1.0.jar
created: META-INF/
inflated: META-INF/MANIFEST.MF
created: gradle/
created: gradle/sample/
inflated: gradle/sample/Sample.class
inflated: gradle/sample/messages.properties
$ cat META-INF/MANIFEST.MF
Manifest-Version: 1.0
Implementation-Version: 1.0
Implementation-Title: Gradle Sample