feat: Update recommended configuration for GPG signing

[wetneb]

This attempts to document the new recommended configuration to sign artifacts with the maven-gpg-plugin as part of the deploy process.

It imitates this PR from the maintainer of the maven-gpg-plugin: https://github.com/xerial/sqlite-jdbc/pull/1082/files

Notes that this requires the maven-gpg-plugin version 3.2.0 or above, not sure if this is worth adding to the documentation as I expect this guide will mostly be followed by people setting up a new project (hopefully using the latest version of the plugin by default).

@cstamas I hope I got it right, feel free to suggest any improvements

Related issue:
might be related to #600?

see also https://issues.apache.org/jira/browse/MGPG-90?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel&focusedCommentId=17825880

Check list:

• Mark if documentation changes are required.
• Mark if tests were added or updated to cover the changes.

[cstamas]

LGTM, but this would work with 3.2.0 m-gpg-p only of course.

[wetneb]

With the release of the 3.2.1 version of the maven-gpg-plugin, this documentation update is less important as 3.2.1 will continue to work like the previous versions.

However, on the long term, this would likely still be a better choice than the current set up, as it removes the dependency on an external GPG agent. Arguably setup-java shouldn't have anything to do with setting up a GPG environment as it's unrelated to Java.

One downside of this method is the additional -Dgpg.signer=bc that needs to be added to mvn package. Perhaps that's something that could be removed in the future, if the maven-gpg-plugin is able to detect by itself that it is running in an environment where GPG hasn't been set up at all.

[cstamas]

Note: 3.2.1 is out, that restores "old way" working.

Still, I'd emphasize that with 3.2.x plugins, the "preferred" way of signing on CI like environments is using BC and passing secrets (key and passphrase) as environment variables. No more hoops and loops, like installing key into GnuPG and getting passphrase via crafted settings.xml should be needed. Ideally, no secret should get onto any disk/persistent storage.

[brunoborges]

The recommendation is useful, but current docs intentionally cover the setup-java-managed GPG path. Recommendation: decide whether to document the BC signer flow as an additional/alternative path in a fresh docs PR.

[Copilot]

Pull request overview

Updates the Maven publishing documentation to reflect a newer recommended GPG-signing approach (using maven-gpg-plugin’s Bouncy Castle signer) rather than importing a key into the runner’s GPG keychain via setup-java.

Changes:

• Removes gpg-private-key / gpg-passphrase inputs from the Maven Central setup-java example.
• Updates the deploy command to use -Dgpg.signer=bc and passes the signing key + passphrase via environment variables.
• Removes the gpg.passphrase server snippet and the older “extra pom.xml setup” guidance from the Maven section.

Show a summary per file

File	Description
docs/advanced-usage.md	Refreshes the Maven Central publishing example to use maven-gpg-plugin’s BC signer workflow and updates the accompanying settings.xml examples accordingly.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 1/1 changed files
• Comments generated: 1