I write about an annoying issue that I encountered when trying to deploy an artifact to Maven Central.
It was a standard CommandAPI release day and I decided to deploy the latest version of the CommandAPI to Maven Central. Doing so is a fairly trivial task and simply consists of running the following:
1
mvnd clean deploy -DcreateChecksum=true -Pci-cd -P Platform.Bukkit -e
This tells Maven to create checksum information, run the ci-cd profile, clean everything, build everything, deploy everything and log any errors in full. Normally, this works with no issues, but instead it failed with the following error message:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-gpg-plugin:3.0.1:sign (sign-artifacts) on project commandapi-bukkit-1.15: Exit code: 2 -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-gpg-plugin:3.0.1:sign (sign-artifacts) on project commandapi-bukkit-1.15: Exit code: 2
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:347)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:330)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:175)
at org.apache.maven.lifecycle.internal.MojoExecutor.access$000(MojoExecutor.java:76)
at org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:163)
at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:160)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:105)
at io.takari.maven.builder.smart.SmartBuilderImpl.buildProject(SmartBuilderImpl.java:204)
at io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run(SmartBuilderImpl.java:78)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: org.apache.maven.plugin.MojoExecutionException: Exit code: 2
at org.apache.maven.plugins.gpg.GpgSigner.generateSignatureForFile(GpgSigner.java:209)
at org.apache.maven.plugins.gpg.AbstractGpgSigner.generateSignatureForArtifact(AbstractGpgSigner.java:203)
at org.apache.maven.plugins.gpg.GpgSignAttachedMojo.execute(GpgSignAttachedMojo.java:204)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:126)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:342)
... 15 common frames omitted
Okay, no biggie… let’s just look online! After a brief search for Failed to execute goal org.apache.maven.plugins:maven-gpg-plugin:3.0.1:sign, I found a number of questions on StackOverflow and issues on various GitHub repositories and in general most resources found the following solution to this problem: Don’t sign artifacts.
To sign or not to sign?
Skipping artifact signing can be done by using the following in your pom.xml file:
1
2
3
4
5
6
7
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>maven-gpg-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
Or by adding the following gpg.skip flag to your command, for example:
1
mvn clean deploy -Dgpg.skip=true
Now, while this is a great and does prevent this sign-artifacts step from failing, it doesn’t meet the requirements for Maven Central artifacts, being:
- JavaDocs and sources must be provided
- File checksums must be provided
- Files should be signed with GPG/PGP
- Other important metadata data (including correct coordinates, project name, description, url, license info, developer info, etc.)
Diagnosing the root cause
Well, I guess at this point it’s time for a bit of a deep dive into how the maven-gpg-plugin works. My first port of call is to stare at the stack trace carefully:
1
2
3
4
5
6
7
Caused by: org.apache.maven.plugin.MojoExecutionException: Exit code: 2
at org.apache.maven.plugins.gpg.GpgSigner.generateSignatureForFile(GpgSigner.java:209)
at org.apache.maven.plugins.gpg.AbstractGpgSigner.generateSignatureForArtifact(AbstractGpgSigner.java:203)
at org.apache.maven.plugins.gpg.GpgSignAttachedMojo.execute(GpgSignAttachedMojo.java:204)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:126)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:342)
... 15 common frames omitted
It didn’t take long to find the maven-gpg-plugin-3.0.1 tag on GitHub, and find the relevant line that threw this exception:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// ----------------------------------------------------------------------------
// Execute the command line
// ----------------------------------------------------------------------------
try
{
int exitCode = CommandLineUtils.executeCommandLine( cmd, in, new DefaultConsumer(), new DefaultConsumer() );
if ( exitCode != 0 )
{
throw new MojoExecutionException( "Exit code: " + exitCode );
}
}
catch ( CommandLineException e )
{
throw new MojoExecutionException( "Unable to execute gpg command", e );
}
And that’s when it hit me. It’s running a command. What if the path to the file it’s trying to sign is too long?
Windows has always had arbitrary regulations on path length or command length or something, and this issue only ever happened for a small set of specific packages which had a longer path name than the others. I mean, the following path is fairly long, but I presume when combined with various other command arguments, it may be too long for Windows to handle gracefully:
1
C:/Users/Jorel/Documents/GitHub/CommandAPI/commandapi-platforms/commandapi-bukkit/commandapi-bukkit-nms/commandapi-bukkit-1.15/target/CommandAPI-9.1.0_17_Aug_2023_(09-25-48am).jar
A simple fix
Assuming it was the path length being too long, I re-cloned the CommandAPI to C:/CmdAPI so the path length would be shorter. Sure enough, this solved my problem and I could go my merry way. I hear there’s a way to poke the registry to allow longer paths, but I’ll cross that bridge if I ever get to it.