Publishing and Artifacts

Inside a MavenPublication you set groupId, artifactId, and version directly. If you omit them, Gradle defaults groupId to project.group, version to project.version, and artifactId to project.name.

publishToMavenLocal installs every publication into your local Maven repository on disk (by default ~/.m2/repository), so other local builds can resolve it via mavenLocal().

Apply the ivy-publish plugin, then inside publishing { publications { } } create a publication of type IvyPublication and add a component such as from components.java.

Apply the maven-publish plugin, then in a publishing { publications { } } block create a publication of type MavenPublication and call from(components["java"]) so it picks up your library's jar and dependencies.

The pom { } block lets you set metadata (name, description, url, licenses, developers, scm) written into the generated pom.xml. You populate it because repositories like Maven Central reject artifacts missing this metadata.

Gradle assembles the name as [baseName]-[appendix]-[version]-[classifier].[extension]. So baseName 'app', version '1.0', classifier 'sources' produces app-1.0-sources.jar. Empty parts are skipped along with their dash.

Inside publishing { publications { ... } }, on the publication, call artifact(tasks.named("fatJar")). That single line adds the fat JAR as an extra file on that publication's coordinates.

Inside the java { } block call withSourcesJar() and withJavadocJar(). Gradle registers sourcesJar and javadocJar tasks and attaches them to the java component, so they publish automatically.

It's a JSON file (module.module) Gradle publishes alongside the POM. It describes a module's variants, their dependencies, and attributes — richer info than a flat POM can express, so Gradle can pick the right variant when resolving.

A SoftwareComponent describes what a project produces for publication (its artifacts and dependencies). The MavenPublication's from(components.java) reads a component to populate the artifacts and POM/metadata that get published.

Each release must include the main JAR plus a sources JAR, a javadoc JAR, a POM, and PGP/GPG signatures (.asc) for every file. Central validation rejects bundles missing any of these.

Inside the repository, call credentials(PasswordCredentials::class). Gradle then reads <repoName>Username and <repoName>Password from gradle.properties or environment variables, where <repoName> is the repository's name.

publishToMavenLocal installs your built artifacts (jar, POM, metadata) into the local Maven cache at ~/.m2/repository, so other local builds on the same machine can resolve them via mavenLocal().

Inside the publishing { repositories { } } block add a maven { } repository and set its url. Optionally give it a name. That tells Gradle where to upload the published artifacts.

It automates Sonatype staging: it creates a staging repository, publishes your artifacts into it, then closes and releases it from the build — so you don't click through the Nexus/Central Portal UI by hand.

isRequired decides whether a missing or failing signature aborts the build. By default it's true. You set it conditionally (e.g. only for releases) so local or SNAPSHOT builds don't fail when no signing key is configured.

It produces a detached PGP signature (.asc file) for each artifact (jar, POM, sources, javadoc). Maven Central requires these signatures so consumers can verify the artifacts are authentic and untampered.

The signing plugin uses PGP/GPG to create detached .asc signature files for your build artifacts. Maven Central requires every published file to be signed so consumers can verify authenticity.

gradle.taskGraph is the resolved DAG of tasks Gradle will run. hasTask('publish') returns true only when a publish task is scheduled. The graph is built after configuration, so the predicate must be read lazily at execution time, not during configuration.

useGpgCmd() shells out to the local gpg binary and its keyring/agent. useInMemoryPgpKeys() takes the raw ASCII-armored key text and passphrase directly, so no gpg install or keyring is needed — ideal for CI.