Skip to content
Where are the .java files? (for compileJava)Where are the resource files like .properties? (for processResources)
Runs the complete build lifecycle: compile Java → process resources → create JARUse this for a full, fresh buildSafest choice for day-to-day workRuns only the JAR packaging task (assumes Java is already compiled)Faster if you haven't changed the source code, only re-jars what exists--no-daemon is an optional flag that tells Gradle "don't use the background daemon process" — useful for CI or if the daemon gets stuck, but not needed for normal development
Build.gradle Configuration
plugins section
plugins {
id 'java'
}
What id 'java' actually does
When you write id 'java' in a , you are loading Gradle's built-in Java plugin. This plugin does several things automatically — you get all of these for free without writing any extra code:
build.gradle
Table 1
Task created
What it does
compileJava
Runs javac on your source files
processResources
Copies .properties and other resource files into the build output
classes
Runs both of the above together
jar
Packages compiled classes into a JAR file
test
Compiles and runs JUnit tests
clean
Deletes the directory
build
build
Runs everything — compile, test, jar
Without id 'java', Gradle doesn't know this is a Java project and none of those tasks exist.
sourceSets
What sourceSets is
A source set tells Gradle where to find the files it needs to compile and package. It answers two questions:
Gradle has one built-in source set called main (for production code) and another called (for test code). You are configuring main here.
test
Gradle's default vs PCSS reality
By default, when you apply id 'java', Gradle assumes this standard Maven directory layout:
my-module/
├── src/
│ └── main/
│ ├── java/ ← Gradle looks for .java files here by default
│ └── resources/ ← Gradle looks for .properties files here by default
└── build/ ← Gradle writes output here
common/dataspec/
├── com/ ← .java files are directly here (no src/main/java wrapper)
│ └── apcc/
│ ├── datamodel/
│ ├── interfaces/
│ └── util/
│ └── analytics/
│ └── analytics.properties
├── bin/ ← Ant writes .class files here (Ant's "build output")
├── prod/ ← Ant writes pcss_ds.jar here
└── build.xml
If you didn't override sourceSets, Gradle would look for Java files in common/dataspec/src/main/java/ — that folder doesn't exist — and find nothing. The build would produce an empty JAR.
What each line in our sourceSets does
sourceSets {
main {
java {
srcDirs = ['.']
exclude 'bin/**', 'prod/**'
}
resources {
srcDirs = []
}
}
}
srcDirs = ['.']
This tells Gradle: "the Java source files start right here in the module's own directory, not in a subfolder." The . means the project directory itself — which for :dataspec is . So Gradle will find and all other .java files recursively.
dataspec
IPCBESettings.java
Commands to generate the jar:
.gradlew.bat :dataspec:build
.gradlew.bat :dataspec:jar --no-daemon
When to use which:
Table 2
Scenario
Command
First build of the module
.gradlew.bat :dataspec:build
Code changed, rebuild everything
.gradlew.bat :dataspec:build
Only re-jar (code unchanged)
.gradlew.bat :dataspec:jar
CI/automated build
.gradlew.bat :dataspec:build --no-daemon
This is the standard, complete, safest approach. Gradle's incremental build automatically skips unchanged steps anyway, so performance is fine.
The :jar variant and --no-daemon flag are optimization/troubleshooting tools — not needed unless you have a specific reason.
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.