Maven "shaded" JAR is prefixed with "original" in the file name

JavaMaven 2

Java Problem Overview


I'm using the "shade" Maven2 plugin to build a monolithic JAR with all Java dependencies bundled together. The relevant section in pom.xml is pretty straightforward:

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-shade-plugin</artifactId>
	<version>1.4</version>
	<executions>
		<execution>
			<phase>package</phase>
			<goals>
				<goal>shade</goal>
			</goals>
			<configuration>
				<finalName>${project.artifactId}-${project.version}-SHADED</finalName>
				<transformers>
					<transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
						<mainClass>com.mypackage.MyClass</mainClass>
					</transformer>
				</transformers>
			</configuration>
		</execution>
	</executions>
</plugin>

However, the build results are odd. It seems that TWO files are actually created by this Maven plugin:

myartifact-1.0.0-SHADED.jar  (zero bytes)
original-myartifact-1.0.0-SHADED.jar  (10 MB)

The JAR file with prefix "original" is properly built, and functions just fine. I suppose I could just rename it to strip off that prefix, and go on my merry way.

However, I very curious as to what may be going on here with the "shade" plugin. It looks like the "original" file is temporary working space type thing, intended to be renamed at the end of the process, and that final renaming simply doesn't complete. There's no obvious explanation for that, though (i.e. filesystem permissions, etc). Has anyone ever seen this before?

Java Solutions


Solution 1 - Java

I know this question is old, but thought it was worth adding the following information.

I think the output originally desired by Steve is that given on this page of the maven-shade-plugin documentation.

<shadedArtifactAttached>true</shadedArtifactAttached>
<shadedClassifierName>jar-with-dependencies</shadedClassifierName>

Solution 2 - Java

Maven's build steps will create the jar target/artifact-version.jar.

Then the shade plugin runs. It normally renames that jar to target/original-artifact-version.jar, and gives the shaded JAR the name target/artifact-version.jar.

However, you're configuring the Shade plugin to use a different name. Unless there's a good reason for that, I'd remove <finalName> from your configuration, and live with what the Shade plugin wants to give you.

Solution 3 - Java

Following @Stewart on providing a slightly better answer (no offense to either :D):

The reason you get the original-* mess can be twofold:

  1. Specifying <finalName> means you want a name different than what Maven gives you by default (ie: same as artifact's name: artifactId-version.jar or artifactId-version-shaded.jar). If you specify a final name that is the same as one of the two, it will try to back the old one up as original-*.jar and then overwrite it with the new shaded one. In your case, you're telling it to make the final JAR *-shaded.jar, which is already the case when it comes out of Maven (before they by default make it into artifactId-version.jar), so it first backs up the old *-shaded.jar as original-*-shaded.jar and then bugs out when writing the bytes to the new *-shaded.jar given the old one disappeared (they seem to rename it).

  2. (Which was my case) Using <shadedClassifierName>, which changes only the suffix Maven uses to generate the *-shaded.jar, in combination with <finalName> can also yield the same results. If you want you can just use <shadedClassifierName> and specify a different suffix and be done with it without having to specify <finalName> with the whole thing. In my case I had both set up to name the output the same thing: ie: artifactId-version-all.jar but using 'all' as Classifier brought me back to the scenario described in #1.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionSteve PerkinsView Question on Stackoverflow
Solution 1 - JavaStewartView Answer on Stackoverflow
Solution 2 - JavaAnonView Answer on Stackoverflow
Solution 3 - JavaRoberto AndradeView Answer on Stackoverflow