Simplify the build command for release publishing

Hi folks,

Context

I'm struggling with the release of the extension and had to double check the action used for Maven release. In this issue I would like to address the build command used to publish the artifact into repository (see https://github.com/camunda-community-hub/community-action-maven-release/blob/cbab52440c897517766c6171ab7d6a02c3eb163b/action.yml#L124-L127)

Before analyzing this - I do use the community-hub-release-parent:1.0.0 which is a perfect place to simplify the build command drastically. The latter has its parent camunda-release-parent:3.7 (All questions on that in a separate issue).

Assuming there are no options and ${RELEASE_PROFILE} is specifying the value-Pcommunity-action-maven-releaseandrelease-versionset to1.2.3`

What I understood

-B for batch
-DskipTests skip tests, we are not to test but to release here
-DnexusUrl=https://oss.sonatype.org/ overrides Camunda Nexus Url with Maven Central
-DserverId=central overrides Camunda Nexus with Maven Central
-Drelease-version=1.2.3 has probably no effect (is a leftover of previously used maven release plugin?)
-Dgpg.sign has probably no effect at all, as far as I understand
initialize is a phase of the default lifecycle (has no effect, since we call deploy)
package is a phase of the default lifecycle (has no effect, since we call deploy)
source:jar is a direct plugin call (could be part of the provided profile)
javadoc:jar is a direct plugin call (could be part of the provided profile)
deploy is the last phase of the default lifecycle
org.apache.maven.plugins:maven-gpg:sign is a direct plugin call (the provided profile already has the invocation of it)
nexus-staging:deploy is a direct plugin call (the plugin is already configured to run in deploy phase)

Issues

First issue here is that the phases are called multiple times, the only relevant here is the deploy phase, since it is the last one inside the default lifecycle (see https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#lifecycle-reference for more information)

The second issue is that the combination of phases with plugins (having already defined executions) leads to multiple invocations of plugins. Here is an example from my log file:

[INFO] Uploading to central: https://oss.sonatype.org:443/service/local/staging/deployByRepositoryId/orgcamunda-2129/org/camunda/bpm/extension/camunda-bpm-process-test-coverage-examples-junit4/1.0.0/camunda-bpm-process-test-coverage-examples-junit4-1.0.0-sources.jar.asc.asc
[INFO] Uploaded to central: https://oss.sonatype.org:443/service/local/staging/deployByRepositoryId/orgcamunda-2129/org/camunda/bpm/extension/camunda-bpm-process-test-coverage-examples-junit4/1.0.0/camunda-bpm-process-test-coverage-examples-junit4-1.0.0-sources.jar.asc.asc (488 B at 22 kB/s)

The file camunda-bpm-process-test-coverage-examples-junit4-1.0.0-sources.jar.asc.asc is a result of duplicate signing.

The second problem with it is that you are overwriting results produced in a certain phase by direct invocation of the plugin. For example, if using Kotlin, JavaDoc is generated by the dokka plugin and not by the javadoc plugin. As a result, the explicit invocation of javadoc plugin lead to ignoring of dokka output and missing docs.. The same applies to sources (which are attached by the pom, but ignored by the invocation).

Solution

The simplified version of this call could look like this:

mvn -B ${{ inputs.maven-additional-options }} ${RELEASE_PROFILE} ${{ inputs.maven-release-options }} deploy

The only addition you then need in the community-hub-release-parent is to add the following plugins to the community-action-maven-release and add some properties:

        <profile>
            <id>community-action-maven-release</id>
            <properties>
                <nexusUrl>https://oss.sonatype.org/</nexusUrl>
                <serverId>central</serverId>
                <skipTests>true</skipTests>
            </properties>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-source-plugin</artifactId>
                    </plugin>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-javadoc-plugin</artifactId>
                    </plugin>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-gpg-plugin</artifactId>
                        <version>1.6</version>
                        <executions>
                            <execution>
                                <id>sign-artifacts</id>
                                <phase>verify</phase>
                                <goals>
                                    <goal>sign</goal>
                                </goals>
                            </execution>
                        </executions>
                        <configuration>
                            <!-- Prevent gpg from using pinentry programs -->
                            <gpgArguments>
                                <arg>--pinentry-mode</arg>
                                <arg>loopback</arg>
                            </gpgArguments>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>

The advantage of the lifecycle phase / profile approach is that it is extensible and don't make any assumptions about the project internals. So if I need to do an additional step on deployment I can hang its execution on the deploy phase (globally) or put it inside the specified profile.

I would be happy to help you with this...

Cheers,

Simon

camunda-community-hub / community-action-maven-release