Introduction

When you build a Spring Boot application, you may see two jar files: the main executable jar and a second file ending in -plain.jar. They are not duplicates. The executable jar is packaged for java -jar, while the plain jar is the ordinary jar output from the standard Java build task.

The Executable Spring Boot Jar

The main Spring Boot jar is produced by the Boot packaging task, often bootJar in Gradle. It contains:

• your compiled classes,
• your resources,
• dependency jars,
• Spring Boot loader classes,
• manifest entries needed for java -jar.

That is why you can usually run it directly:

java -jar build/libs/myapp-0.0.1-SNAPSHOT.jar

Internally, the archive has the Boot layout with directories such as BOOT-INF/classes and BOOT-INF/lib.

The -plain.jar

The -plain.jar file is the regular jar produced by the normal jar task. It usually contains only your project's own compiled classes and resources, not the full dependency set and not the Spring Boot executable layout.

That means it is typically not runnable with java -jar as a standalone Spring Boot application unless you provide the classpath and dependencies yourself.

Why Both Files Exist

Spring Boot builds often keep the standard jar task and the Boot-specific jar task both enabled. The result is:

• a regular Java artifact for standard jar semantics,
• an executable Boot artifact for deployment.

In Gradle terms, the difference is roughly:

1tasks.named("jar") {
2    enabled = true
3}
4
5tasks.named("bootJar") {
6    enabled = true
7}

The Boot plugin then gives the plain jar a classifier such as plain so the two artifacts do not collide.

When You Would Use Each One

Use the executable Boot jar when you want a self-contained application artifact:

java -jar myapp.jar

Use the plain jar when you specifically need a regular library-style jar or want to consume the compiled output in a different packaging flow.

For most application deployments, the executable Boot jar is the one that matters. For some build pipelines, publishing or inspecting the plain jar is still useful because it reflects the project's own classes without the Boot repackaging structure.

How to Disable the One You Do Not Need

If the extra jar is confusing or unnecessary, you can disable one of the tasks. For example, to disable the plain jar in Gradle:

tasks.named("jar") {
    enabled = false
}

Or, less commonly, disable the Boot jar if the project is acting as a library rather than a standalone application:

tasks.named("bootJar") {
    enabled = false
}

Which one you disable depends on whether the module is an app or a reusable library.

Common Pitfalls

• Assuming the plain jar and Boot jar are interchangeable deployment artifacts.
• Trying to run the plain jar with java -jar and expecting Boot dependency resolution to work.
• Publishing both artifacts without understanding which one downstream users should consume.
• Disabling the wrong task in a multi-module build where some modules are apps and others are libraries.
• Confusing the jar classifier with a version difference rather than a packaging difference.

Summary

• The main Spring Boot jar is the executable, dependency-inclusive artifact.
• The -plain.jar is the regular jar output from the standard Java build task.
• The executable jar is usually the correct artifact for application deployment.
• The plain jar is useful when you need regular jar semantics or library-style packaging.
• You can disable either jar or bootJar depending on the module's purpose.