Introduction

Changing the output jar name in a Spring Boot 2 project is usually a build-tool configuration task, not a Spring runtime setting. The exact change depends on whether the project uses Maven or Gradle, and whether you want to rename the plain jar, the executable Boot jar, or both. The safest approach is to configure the build explicitly so your CI, deployment scripts, and artifact repository all see the expected filename.

Maven: Use finalName

In Maven-based Spring Boot projects, the standard way to change the resulting jar name is build.finalName.

1<project>
2  <build>
3    <finalName>my-app</finalName>
4    <plugins>
5      <plugin>
6        <groupId>org.springframework.boot</groupId>
7        <artifactId>spring-boot-maven-plugin</artifactId>
8      </plugin>
9    </plugins>
10  </build>
11</project>

With that configuration, a package build produces target/my-app.jar.

mvn clean package

This is the normal answer when someone asks how to rename the jar in a Spring Boot Maven project.

Gradle: Configure bootJar

In Gradle, you usually configure the bootJar task because that is the executable artifact produced by Spring Boot.

1plugins {
2    id 'org.springframework.boot' version '2.7.18'
3    id 'java'
4}
5
6bootJar {
7    archiveFileName = 'my-app.jar'
8}

If you run:

./gradlew clean bootJar

the artifact will be written with the configured filename under build/libs.

Naming Versus Coordinates

Renaming the jar file does not change the Maven coordinates or the logical project identity. Those still come from values such as groupId, artifactId, and version.

That distinction matters because:

• repository publishing may still use project coordinates
• deployment scripts may reference the physical file name
• generated metadata may differ from the local jar name

If your build and deployment pipeline assumes a name derived from artifactId and version, changing only the local filename may not be enough.

Plain Jar Versus Boot Jar

Spring Boot can produce more than one jar depending on build configuration. In Gradle, for example, jar and bootJar are different tasks.

1jar {
2    archiveFileName = 'my-library.jar'
3}
4
5bootJar {
6    archiveFileName = 'my-service.jar'
7}

If you only rename jar but your deployment uses bootJar, the executable artifact name will not change. This is a frequent source of confusion.

Include Version or Exclude It

Whether to include the version in the filename depends on deployment style.

For immutable release artifacts, versioned names are useful:

<finalName>my-app-2.4.1</finalName>

For server environments that always want a stable name like app.jar, a fixed name may be more convenient:

bootJar {
    archiveFileName = 'app.jar'
}

Be deliberate here. A stable filename simplifies service scripts, but versioned filenames make rollback and artifact auditing easier.

Multi-Module Builds

In a multi-module build, jar naming becomes more important because multiple services may be packaged in the same CI job. If every module ends up producing a generic app.jar, downstream artifact handling gets messy quickly.

A better pattern is to derive names from the module or service identity and let versioning remain visible where appropriate.

Validate the Output Path

After changing the name, verify what your build actually produced.

For Maven:

ls target

For Gradle:

ls build/libs

This sounds trivial, but it catches mistakes such as editing the wrong build file or configuring the wrong task.

Deployment and CI Implications

Changing the jar name can break scripts that copy or run the artifact directly.

Common places to check:

• Dockerfiles using COPY build/libs/*.jar app.jar
• systemd unit files or shell scripts that run java -jar
• CI pipelines that upload a hard-coded filename

Renaming the artifact is easy. Updating the surrounding automation is what usually gets missed.

Common Pitfalls

The most common issue is changing the wrong build setting, such as editing jar while the deployable file is produced by bootJar. Another is assuming that renaming the local file also changes Maven coordinates or published artifact metadata. Teams also often overlook CI scripts, Dockerfiles, and deployment manifests that still reference the old filename. In Maven projects, forgetting finalName and trying to solve the problem inside application properties is another dead end.

Summary

• In Maven, change the Spring Boot jar name with build.finalName.
• In Gradle, configure the bootJar task for the executable artifact.
• Know whether your pipeline uses the plain jar or the Boot jar.
• Renaming the file does not change project coordinates.
• After the change, verify build output and update deployment automation that references the old name.