Introduction

When the Spring Boot packaging plugin creates a file ending in .jar.original or .war.original, it is preserving the plain archive that existed before Spring Boot repackaged it into an executable artifact. This is not usually an error. It is a side effect of the repackage step that turns a normal JAR or WAR into a Boot-specific executable layout with loader classes and nested dependencies.

What Spring Boot Repackaging Actually Does

A normal Java build produces a plain JAR or WAR. Spring Boot's packaging plugin then rewrites that archive so it can be launched directly with embedded Boot support. In the common executable JAR case, the final artifact contains:

• Boot loader classes
• application classes
• dependency JARs stored as nested archives
• manifest entries pointing to the Boot launcher

That final executable archive is not the same file structure as the original plain JAR produced by the standard build lifecycle.

Why the .original File Appears

The plugin needs a place to keep the unmodified artifact while it writes the executable one. So it renames the plain archive to something like:

myapp-0.0.1-SNAPSHOT.jar.original

and leaves the final Boot-ready archive at:

myapp-0.0.1-SNAPSHOT.jar

The .original file is therefore the archive before Spring Boot applied the repackage transformation.

What Is Different Between the Two Files

A plain JAR produced by the standard Java build process is often suitable for classpath use but not necessarily for java -jar execution with embedded Boot behavior. The repackaged Boot archive adds the structure needed for direct launch.

For example, the final executable artifact is typically the one you run:

java -jar target/myapp-0.0.1-SNAPSHOT.jar

The .original file is usually not the one you want to deploy or launch in a normal Spring Boot workflow.

When the .original File Is Useful

Most teams ignore the .original artifact, but it can still be useful in a few situations:

• inspecting what the plain build produced before repackaging
• debugging packaging issues
• comparing the standard archive with the Boot executable archive
• using a different packaging flow that wants the unmodified build artifact

In other words, it is not there for day-to-day execution. It is there because the plugin had an original artifact and then replaced it with a repackaged one.

Maven Example

With Maven, the behavior usually comes from the repackage goal in the Spring Boot plugin configuration.

1<plugin>
2    <groupId>org.springframework.boot</groupId>
3    <artifactId>spring-boot-maven-plugin</artifactId>
4</plugin>

When mvn package runs, Maven first creates the normal archive, then Spring Boot repackages it. That is why the .original file appears after packaging, not before.

WAR Packaging Works the Same Basic Way

The same concept applies to WAR files. If Spring Boot repackages a WAR, the .war.original file is the pre-repackage version and the .war file is the Boot-transformed one.

The exact usefulness of the final WAR depends on whether you intend to run it with embedded Boot support or deploy it to an external servlet container. But the naming pattern still reflects the same repackaging story.

If You Do Not Want the Repackaged Artifact

Sometimes a project wants only a plain library JAR and not an executable Spring Boot archive. In that case, the solution is not to delete .original manually after every build. The right solution is to change the build configuration so the repackage step is disabled or adjusted.

That depends on the build tool and project goal, but the key idea is: the file exists because Boot deliberately repackaged the original artifact.

Do Not Mistake .original for the Deployable Target

A common misunderstanding is assuming the .original file is the “real” application and the executable artifact is a temporary wrapper. In standard Spring Boot deployment, the opposite is usually true. The final .jar or .war is the artifact intended for execution, while .original is a preserved intermediate.

That matters in CI pipelines and deployment scripts. If your automation uploads the wrong file, the application may not start as expected.

Common Pitfalls

The most common mistake is treating .original as an error or corrupted duplicate. It is usually a normal result of Spring Boot repackaging.

Another mistake is deploying the .original file when the environment expects the executable Boot archive.

Teams also forget that the file exists because two stages ran: plain archive creation and then Boot repackaging. Without understanding that sequence, the extra file looks mysterious.

Summary

• A .original JAR or WAR is the plain archive that existed before Spring Boot repackaged it.
• The final .jar or .war is usually the executable artifact intended for deployment.
• Spring Boot keeps the original archive because the repackage step transforms the normal build output.
• The .original file is mostly useful for inspection, debugging, or specialized packaging flows.
• If you do not want it, adjust the build configuration rather than treating the file as a bug.