Introduction

Yes, you can rename a Maven fat JAR, but the right way depends on which plugin is producing it. If you are using the Assembly Plugin's built-in jar-with-dependencies descriptor, the default classifier gets appended automatically unless you change the plugin configuration or switch to a more flexible plugin such as Shade.

Understand Why the Default Name Appears

With the Maven Assembly Plugin, the built-in jar-with-dependencies descriptor usually produces a file name like this:

my-app-1.0.0-jar-with-dependencies.jar

That suffix comes from the assembly identifier. It is not random, and Maven is not ignoring your artifact name. The plugin is attaching a classified artifact to the build output.

Rename It with the Assembly Plugin

If you want the final file to avoid the -jar-with-dependencies suffix, configure the assembly plugin not to append the assembly ID.

1<plugin>
2  <groupId>org.apache.maven.plugins</groupId>
3  <artifactId>maven-assembly-plugin</artifactId>
4  <version>3.7.1</version>
5  <configuration>
6    <archive>
7      <manifest>
8        <mainClass>com.example.Main</mainClass>
9      </manifest>
10    </archive>
11    <descriptorRefs>
12      <descriptorRef>jar-with-dependencies</descriptorRef>
13    </descriptorRefs>
14    <appendAssemblyId>false</appendAssemblyId>
15    <finalName>my-runner</finalName>
16  </configuration>
17  <executions>
18    <execution>
19      <id>make-assembly</id>
20      <phase>package</phase>
21      <goals>
22        <goal>single</goal>
23      </goals>
24    </execution>
25  </executions>
26</plugin>

With that setup, the output becomes my-runner.jar instead of the longer classified name.

Know the Difference Between finalName and Classifiers

Two settings are easy to confuse:

• 'finalName controls the base file name'
• 'appendAssemblyId controls whether the assembly ID such as jar-with-dependencies is appended'

Setting only finalName is often not enough if the classifier is still being appended. That is why people think Maven is "ignoring" the rename.

Consider the Shade Plugin for Executable Fat JARs

If your real goal is a single executable JAR for runtime use, the Maven Shade Plugin is often the better tool. It handles dependency merging, relocation, and executable packaging more cleanly than assembly in many projects.

1<plugin>
2  <groupId>org.apache.maven.plugins</groupId>
3  <artifactId>maven-shade-plugin</artifactId>
4  <version>3.5.2</version>
5  <executions>
6    <execution>
7      <phase>package</phase>
8      <goals>
9        <goal>shade</goal>
10      </goals>
11      <configuration>
12        <finalName>my-runner</finalName>
13        <transformers>
14          <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
15            <mainClass>com.example.Main</mainClass>
16          </transformer>
17        </transformers>
18      </configuration>
19    </execution>
20  </executions>
21</plugin>

In many modern Java projects, Shade is the more maintainable answer if you are building an application rather than a distribution archive.

Verify the Output You Actually Need

Sometimes teams want two artifacts:

• the normal project JAR for repository publishing
• a separate executable fat JAR for deployment

If that is your situation, do not blindly replace the main artifact unless you are sure downstream tooling expects that behavior. Artifact naming is tied to repository publishing, deployment scripts, and CI artifacts, so a rename can have operational side effects.

Prefer Predictable Naming in CI

If the fat JAR is consumed by deployment automation, keep the final name stable across builds unless the version is intentionally part of the deployment contract. Predictable artifact names reduce shell-script complexity and make release pipelines easier to reason about.

Common Pitfalls

• Setting finalName and expecting it to remove the jar-with-dependencies classifier automatically.
• Using the Assembly Plugin when the Shade Plugin is a better fit for executable fat JARs.
• Replacing the main artifact accidentally when downstream tooling still expects the original one.
• Forgetting to verify manifest configuration for the main class after changing packaging plugins.
• Treating file naming as cosmetic when CI and deployment scripts may depend on it.

Summary

• Yes, you can rename a Maven jar-with-dependencies output.
• With the Assembly Plugin, the critical setting is often appendAssemblyId=false.
• 'finalName changes the base name, but classifiers still matter.'
• The Shade Plugin is often a better choice for runnable fat JARs.
• Always confirm how the renamed artifact affects publishing and deployment workflows.