Introduction

Spring Boot packages applications as executable JAR files by default, but the generated file name is configurable. This is useful when your deployment pipeline expects a stable artifact name or when you want clearer build outputs than the default project-version pattern.

Maven: Set the Final Artifact Name

In a Maven-based Spring Boot project, the usual way to control the output name is to set finalName in the build section of pom.xml.

1<project>
2  <build>
3    <finalName>billing-service</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>

After running:

./mvnw package

the packaged artifact will be created with the custom base name, typically as billing-service.jar.

If you want version information in the file name, set finalName accordingly or let Maven keep the default pattern. A stable name is convenient for deployment scripts, but removing the version entirely can make artifact tracking harder.

Gradle: Configure bootJar

In Gradle, the executable Spring Boot artifact is produced by the bootJar task. That is the task you usually want to customize.

tasks.named('bootJar') {
    archiveFileName = 'billing-service.jar'
}

Then build it with:

./gradlew bootJar

If you prefer to keep version and classifier pieces separate, configure the archive components instead of a single file name:

1tasks.named('bootJar') {
2    archiveBaseName = 'billing-service'
3    archiveVersion = '1.0.0'
4}

This gives you more control when CI injects the version dynamically.

Understand jar Versus bootJar

This detail trips people up often. In a Spring Boot Gradle project, bootJar creates the executable fat JAR with dependencies. The plain jar task creates a thin library-style artifact unless you disable it.

So if you change jar but your pipeline publishes bootJar, nothing will appear to change. Always verify which task your build or deployment actually uses.

The same idea applies in Maven. The Spring Boot plugin repackages the artifact for execution, so your naming decision should match the artifact your deployment process consumes.

Keep the Build and Runtime Story Consistent

Renaming the artifact is only one part of the workflow. Deployment scripts, Dockerfiles, Helm charts, and CI job outputs may all refer to the old file name. If your Dockerfile currently says COPY build/libs/demo-0.0.1-SNAPSHOT.jar app.jar, changing the Gradle task without changing the Docker build will break the image pipeline even though the Java build itself still succeeds.

A stable name can simplify those downstream steps:

1FROM eclipse-temurin:21-jre
2WORKDIR /app
3COPY build/libs/billing-service.jar app.jar
4ENTRYPOINT ["java", "-jar", "app.jar"]

That pattern is common in containerized Spring Boot deployments because the image no longer needs to know the project version at copy time.

Choose a Naming Strategy That Fits Operations

A few common approaches work well:

• Stable file name such as app.jar for simple container images
• Versioned file name for artifact repositories and manual rollbacks
• Environment-neutral base name so the same build can move across stages

A good rule is to keep the artifact name predictable for automation and keep version information somewhere that operations can still inspect easily.

Common Pitfalls

• In Gradle, changing jar instead of bootJar is the most common mistake.
• Removing version information entirely can make debugging deployments harder later.
• Some CI pipelines assume the default artifact pattern, so rename carefully and update the pipeline in the same change.
• If both plain and executable JARs are produced, make sure they do not collide on the same output name.

Summary

• In Maven, use build.finalName to control the packaged JAR base name.
• In Gradle, customize the bootJar task because that is usually the executable artifact.
• Verify which artifact your deployment pipeline actually consumes before changing names.
• Pick a naming scheme that balances automation convenience with traceability.