Secrets for in-memory vs file gpg signing configuration confusion

[compscidr]

I noticed that the syntax for both in-memory and gpg file based signing configuration is diffferent, which is confusing and not really documented so well.

For instance, here: https://github.com/vanniktech/gradle-maven-publish-plugin/blob/main/docs/central.md?plain=1#L226, the file based syntax for gradle.properties is:

signing.keyId=12345678
signing.password=some_password
signing.secretKeyRingFile=/Users/yourusername/.gnupg/secring.gpg

so I'd expect the in memory syntax to be something like:

signing.inMemoryKey=some bytes of in memory key

however, the documentation: https://github.com/vanniktech/gradle-maven-publish-plugin/blob/main/docs/central.md?plain=1#L238 only shows the syntax in the environment variable tab, which is:

ORG_GRADLE_PROJECT_signingInMemoryKey=exported_ascii_armored_key
ORG_GRADLE_PROJECT_signingInMemoryKeyId=12345678
ORG_GRADLE_PROJECT_signingInMemoryKeyPassword=some_password

or in the gradle.properties syntax:

signingInMemoryKey=exported_ascii_armored_key
signingInMemoryKeyId=12345678
signingInMemoryKeyPassword=some_password

This also leaves me wondering how I would do the file based config using environment variables. For instance would it be?:

ORG_GRADLE_PROJECT_signing.keyId=12345678
ORG_GRADLE_PROJECT_signing.password=some_password
ORG_GRADLE_PROJECT_signing.secretKeyRingFile=/Users/yourusername/.gnupg/secring.gpg

I'm curious whether the environment variable supports the . character, and if not, what should it be? An _?. Another option would be just camelCase like the in memoryKey, but like I said, it is unclear from the docs. I was able to determine the gradle.properties for the in memory key based on the integration test here: https://github.com/vanniktech/gradle-maven-publish-plugin/blob/da599468864f7be7f0c694f174baa797ba8bf189/plugin/src/integrationTest/kotlin/com/vanniktech/maven/publish/ProjectSpecRunner.kt#L229

I'd be happy to make a PR to either a) document both configs in the gradle.properties format and environment variable format and/or b) change the format to be consistent between both the in-memory and file based options - just need some guidance as to your preferences there.

[lnhrdt]

I also found the naming conventions here quite confusing. I took a deep dive into the configuration just now, and I think I’ve managed to get a handle on it—so I thought I’d share my findings.

The main issue seems to be that some properties are defined by this plugin, while others come directly from Gradle, leading to inconsistencies. The documentation from both this plugin and Gradle glosses over some of these nuances. For example, signing.keyId, signing.secretKeyRingFile, and signing.password originate from the Gradle Signing Plugin itself. The Signing Plugin provides these conventions for file-based key configuration but lacks any predefined properties for in-memory keys—these must be set manually through the useInMemoryPgpKeys DSL function. I’m basing this on the fact that there’s no InMemoryPgpSignatoryFactory in their source code (only a provider) and on the examples in Gradle’s documentation.

In contrast, the signingInMemoryKey, signingInMemoryKeyId, and signingInMemoryKeyPassword values are defined specifically by this plugin.

I also found the ORG_GRADLE_PROJECT_ prefix confusing, along with other uppercase properties like SONATYPE_HOST. I understand ORG_GRADLE_PROJECT_ to be the convention for setting project properties via environment variables and suspect its use as a property prefix in this plugin may be an oversight. I believe a more standard and simplified approach would make configuration clearer.

I saw @gabrielittner added a documentation label. If you’re open to suggestions, I'd recommend introducing new in-memory key configuration properties that align more predictably with Gradle's Signing Plugin (while deprecating the current ones), removing the use of a ORG_GRADLE_PROJECT_ prefix in properties, and standardizing other properties to a conventional lowercase format with dot separators. I think these changes would go a long way toward making the plugin easier to learn and use!