Maven 'deploy' cause code repackaging after the signing operation (BAD signature)

Question

I want to deploy an artifact to Sonatype OSS repository.

When I deploy with the following command, the signatures are invalid.

mvn clean source:jar javadoc:jar install gpg:sign deploy

> gpg --verify  target/security-versions-1.0.1.jar.asc
gpg: assuming signed data in 'target/security-versions-1.0.1.jar'
gpg: Signature made 10/20/15 11:45:50 Eastern Daylight Time using RSA key ID 63E38ACF
gpg: BAD signature from "Philippe Arteau <[email protected]>" [ultimate]

If I remove the deploy goal, the signatures are GOOD.

mvn clean source:jar javadoc:jar install gpg:sign

> gpg --verify  target/security-versions-1.0.1.jar.asc
gpg: assuming signed data in 'target/security-versions-1.0.1.jar'
gpg: Signature made 10/20/15 11:54:34 Eastern Daylight Time using RSA key ID 63E38ACF
gpg: Good signature from "Philippe Arteau <[email protected]>" [ultimate]

I realize that, after the sign operation, the jars were packaged a second time. How can I deploy without compromising the signatures?

Problematic operations:

[INFO] --- maven-gpg-plugin:1.5:sign (default-cli) @ security-versions ---

You need a passphrase to unlock the secret key for
user: "Philippe Arteau <[email protected]>"
4096-bit RSA key, ID 63E38ACF, created 2013-05-12

[...]

[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ security-versions ---
[INFO] Building jar: C:\Code\workspace-java\maven-security-versions\target\security-versions-1.0.1.jar
[INFO]
[INFO] --- maven-plugin-plugin:3.2:addPluginArtifactMetadata (default-addPluginArtifactMetadata) @ security-versions ---
[INFO]
[INFO] --- maven-source-plugin:2.2.1:jar-no-fork (default) @ security-versions ---
[INFO] Building jar: C:\Code\workspace-java\maven-security-versions\target\security-versions-1.0.1-sources.jar

The second part should not be done since the compilation and packaging has already occurs.

Answer 1

Configuration

Their is a workaround that need adding yet another snippet of XML in the pom.xml.

<build>
    <plugins>
        <plugin>
            <inherited>true</inherited>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-deploy-plugin</artifactId>
            <version>2.8.2</version>
            <configuration>
                <updateReleaseInfo>true</updateReleaseInfo>
            </configuration>
            <executions>
                <execution>
                    <goals>
                        <goal>deploy</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-gpg-plugin</artifactId>
            <version>1.6</version>
            <executions>
                <execution>
                    <id>sign-artifacts</id>
                    <goals>
                        <goal>sign</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

This sample was found in this response. Although more generic, the person was probably hitting the same bug.

The complete deployment can be trigger with : mvn clean source:jar javadoc:jar deploy (Important: Do not mention install or verify)

Caveat

The configuration make sure gpg:sign is run prior the maven-deploy-plugin.

A side effect can occurs if verify/install/sign plugin is mention. (mvn clean source:jar javadoc:jar verify install gpg:sign deploy) The package will be sign up to 4 times recursively (signature being signed..).

oss-parent

Having the oss-parent reference might trigger gpg:sign because of this.