Gradle build与bootJar的区别解析：为何选择bootJar而非build生成构件

Great question! Let’s break down the core distinctions between these two commands clearly, then dive into why you’d still reach for bootJar even when build gets the job done.

1. Task Scope & Execution Flow #

• gradle build is a standard lifecycle aggregate task that runs the entire build pipeline from start to finish. For a Spring Boot project, this means it’ll execute:
  • Code compilation (compileJava)
  • Unit/integration tests (test)
  • Code quality checks (like check, if configured)
  • Archiving tasks (including bootJar for Spring Boot projects)
    It’s the "full build" command that ensures your code is valid, tested, and ready for formal distribution.
• gradle bootJar is a single, specialized task provided by the Spring Boot Gradle Plugin. It only focuses on generating the executable Spring Boot JAR file—no tests, no code checks, no extra pre-build steps. It skips all validation tasks unless you explicitly configure dependencies for them.

2. Output Artifacts #

• When you run gradle build on a Spring Boot project, you’ll get two JAR files by default:
  • The main executable JAR (e.g., my-app-1.0.jar): This contains your compiled code plus all dependent libraries, and can be run directly with java -jar.
  • A "plain" JAR (e.g., my-app-1.0-plain.jar): This is a standard JAR with just your project’s classes (no dependencies), meant to be used as a dependency in other projects.
• gradle bootJar only generates the executable Spring Boot JAR. It doesn’t create the plain JAR, so you get exactly what you need for running the app without extra, unused files.

3. Primary Use Cases #

• gradle build is for full project validation and release preparation. Use it when you want to ensure everything works as expected—tests pass, code meets quality standards, and all required artifacts are generated. It’s the go-to command in CI/CD pipelines for formal builds.
• gradle bootJar is for fast, iterative development and quick deployments. Use it when you’ve already tested your code and just need to package it up to run locally or deploy to a test environment. It cuts out the extra steps to save time during rapid development cycles.

Even though build produces the executable JAR, there are solid reasons to reach for bootJar specifically:

• Faster Builds: Skipping tests, checks, and other pre-build tasks can save significant time, especially in large projects where running the full test suite takes minutes. When you’re iterating quickly, every second counts.
• Targeted Workflow: If you only need the executable JAR (no plain JAR, no validation), bootJar gives you exactly that without unnecessary overhead. No need to wait for tasks you don’t care about right now.
• Customization Flexibility: You can tweak the bootJar task directly in your build script (e.g., rename the output JAR, exclude certain dependencies, add extra resources) and run just that task to see changes immediately, instead of triggering the entire build pipeline.
• Avoid Unnecessary Failures: Sometimes tests might fail for unrelated reasons (like flaky integration tests) when you just want to run your app. bootJar lets you bypass those failures and get a working JAR quickly for debugging.

内容的提问来源于stack exchange，提问作者Jiji