Introduction

mvn package and spring-boot:repackage are related, but they are not the same operation. mvn package runs the normal Maven lifecycle up to the package phase, while spring-boot:repackage takes the packaged artifact and rewrites it into a Spring Boot executable archive.

mvn package is a Maven lifecycle phase

When you run mvn package, Maven performs the standard build steps up to the package phase:

• compile main sources
• run tests if not skipped
• create the main artifact such as a JAR or WAR

For a plain Java project, that artifact is usually just your compiled classes plus metadata. It is not automatically an executable Spring Boot fat JAR.

mvn package

If no Spring Boot plugin is bound to the lifecycle, this is all that happens.

spring-boot:repackage rewrites the archive

The Spring Boot Maven plugin adds a separate goal called repackage. Its job is to take an already-built archive and turn it into a bootable Spring Boot artifact.

That usually means:

• moving application classes into Boot's expected layout
• bundling dependencies into the archive
• writing the manifest so java -jar can launch the app

mvn spring-boot:repackage

If your project packages as a JAR and uses an embedded server, the result is the familiar executable Spring Boot JAR you can run directly:

java -jar target/app.jar

Without repackaging, a normal JAR may exist, but it often will not have Boot's launcher structure or bundled runtime dependencies.

In many projects, mvn package already triggers repackaging

This is where the confusion usually comes from. In a typical Spring Boot project, the plugin is configured so that repackage is bound to the package phase. That means:

mvn package

already performs both steps:

1. Maven packages the artifact
2. the Spring Boot plugin repackages it

A minimal plugin setup looks like this:

1<build>
2  <plugins>
3    <plugin>
4      <groupId>org.springframework.boot</groupId>
5      <artifactId>spring-boot-maven-plugin</artifactId>
6    </plugin>
7  </plugins>
8</build>

In that configuration, you usually do not call spring-boot:repackage manually because it already happens during packaging.

When the difference matters

The distinction matters in a few cases:

• you are debugging why the output JAR is not executable
• you are working on a non-Boot Maven module where only package runs
• you intentionally disable or customize the Boot plugin execution
• you are producing both original and repackaged artifacts

For example, if you want to keep the plain original JAR alongside the executable one, Spring Boot plugin configuration becomes important.

The simplest mental model is:

• 'package builds the artifact'
• 'repackage transforms that artifact into Boot's executable layout'

Common Pitfalls

• Assuming mvn package always creates an executable Spring Boot JAR even when the Boot plugin is not configured.
• Thinking spring-boot:repackage replaces the Maven build lifecycle rather than running after packaging.
• Running repackage manually and forgetting it needs an already packaged artifact to work on.
• Confusing a plain packaged JAR with a Boot fat JAR that includes launcher structure and dependencies.
• Debugging the wrong command when the real issue is plugin binding in the pom.xml.

Summary

• 'mvn package is the standard Maven lifecycle phase that builds the artifact.'
• 'spring-boot:repackage rewrites that artifact into a Spring Boot executable archive.'
• In many Spring Boot projects, mvn package already triggers repackage because the plugin is bound to the package phase.
• A plain Maven package and a Boot executable JAR are not necessarily the same thing.
• If the output is not bootable, inspect the Spring Boot Maven plugin configuration first.