skip to content

How would you inspect the POM Gradle will publish without actually pushing anything to a repository?

level: middleimportance: should knowfreq 50%

answer

  1. generatePomFileFor<Pub>Publication
  2. build/publications/<pub>/pom-default.xml
  3. no network
  4. publish tasks depend on it
  5. generateMetadataFileFor<Pub>Publication (.module)

basics

~10 s

Run generatePomFileFor<Pub>Publication. It writes the pom.xml into build/publications/<pub>/pom-default.xml so you can read it without publishing to any repository.

solid answer

~30 s

Each `MavenPublication` gets a generated `generatePomFileFor<PubName>Publication` task. Running it produces the exact `pom.xml` Gradle would upload — written to `build/publications/<pubName>/pom-default.xml` — **without** contacting any repository. This is the safe way to verify dependency coordinates, scopes, the `<dependencyManagement>` block, and any custom POM fields before a real publish. The publish/install tasks depend on this generation task, so it always runs as part of publishing; running it standalone just lets you inspect the output. It's invaluable in CI pre-flight checks (e.g., assert the POM lists expected dependencies) and when debugging why a consumer resolved an unexpected transitive dependency.

code

bash · 2 lines
bash
./gradlew generatePomFileForMavenJavaPublication
cat build/publications/mavenJava/pom-default.xml

go deeper

for a junior

Know generatePomFileFor<Pub>Publication writes a pom.xml under build/publications without publishing.

for a middle

Use it to verify dependency scopes/coordinates pre-publish and locate pom-default.xml.

for a senior

Add CI assertions on the generated POM and reason about POM vs .module metadata divergence.

for a principal

Treat POM/module generation as a contract artifact; gate releases on automated POM validation across modules.

## The inspection task For every publication, `maven-publish` registers: ``` generatePomFileFor<PublicationName>Publication ``` It serializes the publication's metadata into a Maven `pom.xml`. The output lands in: ``` build/publications/<publicationName>/pom-default.xml ``` No network, no repository — purely local file generation. Because the real `publish<Pub>PublicationTo...` tasks **depend on** this task, the POM you inspect is byte-for-byte what gets uploaded. ## Why inspect first The POM is derived from your declared dependencies and their **configurations** (api vs implementation map to compile vs runtime scope), plus any `pom { }` customization and platform/BOM imports. Subtle issues — a dependency leaking into the wrong scope, a missing constraint, a wrong version from a `Provider` — show up here long before a consumer complains. ## Companion: Gradle Module Metadata Gradle also publishes `*.module` (Gradle Module Metadata) alongside the POM, generated by `generateMetadataFileFor<Pub>Publication`. The POM is the Maven-compatible view; the `.module` file carries richer variant info. Inspect both when diagnosing resolution differences between Gradle and Maven consumers. ## Practical flow ```bash ./gradlew generatePomFileForMavenJavaPublication cat build/publications/mavenJava/pom-default.xml ``` In CI you can fail the build if the generated POM is missing an expected `<dependency>` or contains a forbidden one, catching contract regressions early.

  • Where does the generated POM file end up?
    build/publications/<publicationName>/pom-default.xml.
  • What related task produces Gradle Module Metadata, and why care?
    generateMetadataFileFor<Pub>Publication writes the *.module file; it carries variant/attribute info richer than the POM, used by Gradle consumers.
  • Why might the published POM's dependency scopes differ from your build script?
    api/implementation/compileOnly map to Maven compile/runtime/provided scopes, so the POM reflects the dependency's configuration, not a literal copy.

saying these in an interview costs you the question

  • Thinking you must publish to a repo to see the POM — generation is a separate, offline task.
  • Forgetting Gradle also emits *.module metadata that can change consumer resolution.

context

resolving links…