Java Maven and Gradle Basics Explained with Examples

Maven's conventional source directory is src/main/java, and tests belong in src/test/java. Resources have their own neighboring directories. The build writes generated output under target, keeping compiled classes and packaged JARs separate from authored source. Following these conventions avoids extra configuration and makes projects recognizable to collaborators and editors. A source file placed in an arbitrary directory may not be compiled unless you change the configured source roots.

groupId, artifactId, and version identify an artifact. Dependencies use those coordinates to select libraries from repositories. Your project's coordinates do not automatically declare its Java package names, although organizations often keep them related. A dependency version should be explicit or managed through a documented parent or dependency-management section. Avoid assuming that changing artifactId renames every class or package; the build identity and source namespace serve different roles.

mvn compile runs the steps necessary to compile main source. mvn test includes compilation and executes configured tests. mvn package continues through testing and creates the configured artifact, commonly a JAR. mvn clean removes generated build output before another lifecycle action. Commands can be combined, such as mvn clean package. Tests are not a cosmetic step to skip whenever inconvenient; a failed test should be understood before publishing the resulting application.

A build should state its platform target instead of relying on whichever default happens to be installed. The Maven Compiler Plugin's release setting targets Java 17 in the sample configuration. Maven itself also runs on a selected Java installation, which mvn -version reports. A JDK capable of the configured release is still required. The release setting does not download a missing compiler or make a Java 17 runtime execute unsupported newer bytecode.

Maven resolves declared dependencies into a local repository and constructs appropriate classpaths. A dependency with test scope is available to tests but not normally packaged as a runtime requirement. Runtime packaging still depends on the chosen artifact strategy: an ordinary JAR does not automatically bundle all dependencies into one executable file. Distinguish a plain library JAR, an executable JAR with manifest configuration, and a distribution including dependency JARs.

Gradle's Java plugin supplies tasks such as compileJava, test, and jar. A Java toolchain and source compatibility configuration control its compiler selection and platform target. The Gradle wrapper lets collaborators invoke a project-selected Gradle version through gradlew rather than depending solely on a machine-wide install. Maven has a wrapper too. Commit wrapper files according to the tool's guidance, but keep downloaded caches and generated target or build directories out of version control.

Create the displayed directory layout, save the POM and BuildLabel source, and run the package command from the root containing pom.xml. Inspect target/classes and the generated JAR before launching it. Change the artifact version and predict the new filename; do not assume the Java class name changes too. Add a deliberately invalid Java statement and confirm the build fails before packaging a new successful artifact. Restore the source and rebuild. Finally, write a README with the required Java release, build command, and exact launch command. If using Gradle instead, document the equivalent wrapper tasks and resulting JAR location. A collaborator should be able to build from authored files without receiving your target directory.