This page is the entry point for developers working with or contributing to the Spring Boot repository. It covers the primary communication channels for getting help, the process for reporting bugs and requesting features, the contribution workflow, and the mechanics of building the project locally. For detailed IDE setup instructions, see IDE Setup and Configuration. For a full breakdown of support channels, see Support Channels and Community Resources. For contributing workflow specifics (DCO, formatting, Checkstyle), see Contributing and Development Workflow.
Spring Boot routes different request types to different channels. Using the wrong channel slows down response time.
| Request Type | Channel | Details |
|---|---|---|
| General usage questions | Stack Overflow | Use the spring-boot tag |
| Bug reports | GitHub Issues | Provide version, OS, JVM; attach a minimal reproducer |
| Feature requests | GitHub Issues | Describe the use case, not just the desired API |
| Security vulnerabilities | spring.io/security-policy | Do not use GitHub issues for CVEs |
| Enterprise support | VMware Tanzu | Dedicated commercial support via enterprise.spring.io |
| Code of Conduct violations | [email protected] | Governed by the Contributor Covenant |
The policy is spelled out in SUPPORT.adoc1-29 and repeated in CONTRIBUTING.adoc14-29
Before opening an issue or asking a question, the recommended resolution order is:
Diagram: Help Resolution Flow
Sources: README.adoc51-60 SUPPORT.adoc1-29
When opening a GitHub issue, include the following to avoid back-and-forth:
java -version output)```)The project uses GitHub's issue tracker exclusively for bugs and enhancements, not for support questions. See CONTRIBUTING.adoc14-22 for the full guidance.
Security vulnerabilities must never be disclosed in public GitHub issues. Follow the responsible disclosure process at the spring.io/security-policy URL described in CONTRIBUTING.adoc25-29
Diagram: Contribution Workflow and Key Files
Sources: CONTRIBUTING.adoc1-64 git/hooks/prepare-forward-merge1-71 .github/PULL_REQUEST_TEMPLATE.md1-29
Every commit must include a Signed-off-by trailer. This replaced the previous CLA process as of January 2025. The trailer format is:
Signed-off-by: Your Name <[email protected]>
| Convention | Mechanism | How to Run |
|---|---|---|
| Source formatting | Spring JavaFormat plugin | ./gradlew format |
buildSrc formatting | Same plugin, separate invocation | ./gradlew -p buildSrc format |
| Static analysis | Checkstyle (configured via buildSrc) | ./gradlew checkstyleMain checkstyleTest |
| Full verification | All checks + tests | ./gradlew check |
| Kotlin analysis | Detekt (config/detekt/config.yml) | Runs as part of check |
Note: The SPRING_PROFILES_ACTIVE environment variable can affect test results. Run unset SPRING_PROFILES_ACTIVE before executing ./gradlew check if it is set. See CONTRIBUTING.adoc39-57
Checkstyle and Kotlin convention details are covered in Checkstyle and Kotlin Conventions.
The PR template at .github/PULL_REQUEST_TEMPLATE.md1-29 asks contributors to:
#<number> syntaxThe project requires JDK 25 to build. The Gradle wrapper handles the Gradle version automatically.
Build only (no tests):
Full build with tests:
publishToMavenLocal compiles all ~200 subprojects and installs their artifacts to the local Maven cache (~/.m2/repository). This is the fastest path to using a locally-modified Spring Boot in another project.
See README.adoc86-104 for the canonical instructions.
For a detailed explanation of the Gradle multi-project build structure, see Multi-Project Build Structure and Gradle Properties and Version Management.
Diagram: IDE Setup Entry Points
Sources: eclipse/spring-boot-project.setup1-431 CONTRIBUTING.adoc44-46
The Oomph setup file at eclipse/spring-boot-project.setup1-431 provisions a complete Eclipse workspace in a single step. It installs the Spring JavaFormat Eclipse plugin from repo.spring.io/javaformat-eclipse-update-site, Buildship for Gradle integration, and M2E for Maven metadata. It also configures working sets that group the ~200 subprojects into logical categories (platform, core, module, loader, starter, build, etc.) matching the layout described in Project Structure and Module Organization.
Full IDE setup instructions are in IDE Setup and Configuration.
| File | Purpose |
|---|---|
| README.adoc | Top-level project overview, getting help, building, guides |
| CONTRIBUTING.adoc | Full contribution guide: DCO, formatting, Checkstyle, PR process |
| SUPPORT.adoc | Concise support channel index |
| eclipse/spring-boot-project.setup | Eclipse Oomph provisioning descriptor |
| .github/PULL_REQUEST_TEMPLATE.md | PR description template |
| git/hooks/prepare-forward-merge | Git hook that rewrites merge commit messages for branch-forward workflow |
The repository includes a prepare-commit-msg hook at git/hooks/prepare-forward-merge1-71 written in Ruby. When a merge commit is detected, it:
Fixes gh-NNN or Closes gh-NNN references from the source commit.Fixes gh-1234 in 4.1.x) to the merge commit message.origin/ prefix).The main branch variable is set at git/hooks/prepare-forward-merge7 to 4.1.x, which reflects the current maintenance branch. This hook is relevant only to maintainers performing forward-merges between release branches.