.gitignore for Java Projects

Java projects produce significant build artifacts that must be excluded from version control. Whether you use Maven or Gradle, a proper .gitignore prevents committing compiled classes and build caches.

Build tool output:

• target/ — Maven's default output directory containing compiled .class files, packaged .jar/.war files, and test reports. This directory is fully regenerated by mvn clean install.
• build/ — Gradle's default output directory. Same purpose as Maven's target/.
• .gradle/ — Gradle's project-level cache storing dependency metadata, task output caches, and file hashes. This can grow to hundreds of megabytes in large projects.
• out/ — IntelliJ IDEA's default compilation output directory when not using Maven or Gradle.

Compiled files:

• *.class — Compiled Java bytecode. These are always reproducible from source and should never be versioned.
• *.jar, *.war, *.ear — Packaged application archives. Your CI/CD pipeline builds these; they do not belong in source control.

IDE-specific patterns:

• .idea/ — IntelliJ IDEA project configuration. Most files are user-specific (window layouts, run configurations with local paths). Some teams choose to commit .idea/codeStyleSettings.xml for shared formatting rules.
• *.iml — IntelliJ module files containing local dependency paths.
• .settings/, .project, .classpath — Eclipse workspace files.

Other patterns:

• hs_err_pid*.log — JVM crash logs generated by HotSpot.
• .factorypath — Annotation processor configuration generated by Eclipse.

Key takeaway: Commit your build tool wrapper (mvnw, gradlew) and wrapper properties, but never commit compiled output. Note that gradle/wrapper/gradle-wrapper.jar should be committed so developers can bootstrap Gradle without installing it first.