Getting started with the Lab 04 project

Welcome to the thrilling world of build automation where typing a command does what your coworker used to do by hand and then complain about. Start with a clean project folder and either run gradle init or create settings.gradle and the standard src structure by hand if you enjoy small rituals. Gradle will generate a skeleton that avoids most of the chaos later.

Create the build script that does not haunt you

Drop a build.gradle or build.gradle.kts in the project root. Apply the Java plugin and any other plugins required by Lab 04 exercises. Use readable plugin and group names so your build file reads like documentation and not an unlucky fortune.

plugins {
    id 'java'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.slf4j slf4j-api 1.7.36'
    testImplementation 'junit junit 4.13.2'
}

The exact dependencies will vary with the lab, but stick to implementation for compile time libraries and testImplementation for test libraries. That keeps your classpath sane and your future self less angry.

Declare tasks and automate annoyance removal

Gradle tasks are your friends when used responsibly. Name custom tasks clearly so anyone reading the build file understands what happens without a séance. Keep task logic focused and idempotent to keep the lab reproducible.

• Create a task for repetitive setup steps
• Use built in tasks where possible to avoid reinventing wheel shaped pain
• Expose a check or build task that runs tests and verifies artifacts

Small example task

tasks.register('printHello') {
    doLast {
        println 'Hello lab 04'
    }
}

Add the Gradle Wrapper and stop version guesswork

Run gradle wrapper to generate the wrapper scripts. Commit the wrapper files so collaborators never argue about which Gradle version works. Pin a Gradle version in the wrapper properties to avoid surprising breaks when a new Gradle feature shows up uninvited.

Run the build and inspect the output

Use the wrapper to run the build so everyone is using the same toolchain. From the project root run ./gradlew build. Build artifacts land in the build folder and test reports are under build so you can open them and see what failed without guessing.

• Run ./gradlew tasks to list available tasks and avoid wild guesses
• Use ./gradlew build to run the full build including tests
• If things fail add --stacktrace to get the diagnostic messages you actually need

Debugging and tips for not losing time

When the build throws mysterious exceptions use the Gradle switches that tell the truth. Add --stacktrace to see the full trace. Add --info or --debug when you want more verbosity and fewer surprises.

Commit the wrapper scripts to version control. Pin the Gradle distribution in the wrapper properties. These steps are boring but they save your team from environment debates that last longer than a code review.

Summary and quick checklist

This guide walked through the Lab 04 essentials from project initialization to running builds with the wrapper and creating tasks and dependencies that keep the workflow reproducible. Follow the checklist and you will have fewer build tragedies.

• Initialize the project with gradle init or by creating settings and source folders
• Create a clear build.gradle or build.gradle.kts with plugins and repositories
• Declare dependencies with implementation and testImplementation
• Register helpful custom tasks with sensible names
• Generate and commit the Gradle Wrapper with gradle wrapper
• Run ./gradlew build and inspect the build folder and test reports