skip to content

How is the .module file produced and published, and how do you enable or disable Gradle Module Metadata publication?

level: juniorimportance: should knowfreq 30%

answer

  1. maven-publish auto-generates .module
  2. task type GenerateModuleMetadata
  3. on by default for JVM
  4. POM carries redirect marker
  5. disable via task.enabled = false

basics

~20 s

The maven-publish (or ivy-publish) plugin generates the .module file automatically and publishes it with your POM and jars. GMM publication is on by default; you can toggle it via tasks.withType<GenerateModuleMetadata>().configureEach { enabled = ... }.

solid answer

~40 s

When you apply `maven-publish`, Gradle wires up a `generateMetadataFileForXxxPublication` task (type `GenerateModuleMetadata`) that produces the `.module` JSON from your project's variants and publishes it alongside the POM and artifacts — it is enabled by default. The generated POM also gets a marker so GMM-aware consumers redirect to the `.module`. You rarely write metadata by hand. To disable GMM publication (e.g. for a repo or audience that mishandles it) you disable the `GenerateModuleMetadata` task. Gradle deliberately warns if you publish GMM derived from POM-only resolved dependencies, because such metadata can be inaccurate — that warning surfaces as a `<!-- This module was ... -->` note inside the published `.module`.

code

kotlin · 15 lines
kotlin
plugins {
    `java-library`
    `maven-publish`
}

publishing {
    publications {
        create<MavenPublication>("lib") { from(components["java"]) }
    }
}

// Opt out of Gradle Module Metadata if a consumer can't handle it:
tasks.withType<GenerateModuleMetadata>().configureEach {
    enabled = false
}

go deeper

for a junior

Know maven-publish creates and publishes the .module automatically and that it's enabled by default.

for a middle

Name the GenerateModuleMetadata task and show how to disable it.

for a senior

Explain the POM redirect marker and Gradle's accuracy warnings/validation around generated metadata.

for a principal

Decide publication policy (GMM on/off) per consumer ecosystem and tooling maturity across the org.

## Generation Applying the `maven-publish` plugin registers, per publication, a task of type `GenerateModuleMetadata` named `generateMetadataFileFor<PubName>Publication`. It serializes the project's outgoing variants (`apiElements`, `runtimeElements`, plus any feature variants/capabilities) into the `.module` JSON, including dependencies, constraints, attributes, and artifact checksums. ## Publication The `publish` (and `publishToMavenLocal`) tasks upload: - the artifacts (jars), - the `.pom` (with a comment marker pointing to GMM), - the `.module` file. GMM publication is **enabled by default** for Java/JVM projects. ## Enabling / disabling ```kotlin plugins { `maven-publish` } tasks.withType<GenerateModuleMetadata>().configureEach { // Turn GMM publication off (e.g., a consumer toolchain that can't read it): enabled = false } ``` Disabling means only the POM/Ivy file is published, so variant fidelity is lost for downstream Gradle consumers. ## Accuracy warnings Gradle refuses or warns when the metadata it would publish may be **untrustworthy** — for instance, if a component version is derived from a dependency resolved only via a POM, or you mutate the published versions in non-resolvable ways. You can suppress specific cases: ```kotlin tasks.withType<GenerateModuleMetadata>().configureEach { suppressedValidationErrors.add("enforced-platform") } ``` ## Why it's automatic Because the build already knows its variant model (from the `java`/`java-library` plugin), Gradle can emit a faithful `.module` with no manual JSON authoring — hand-editing is discouraged and unnecessary.

  • What is the type of the task that generates the .module file?
    `GenerateModuleMetadata` — registered per publication as `generateMetadataFileFor<PubName>Publication` by the publish plugin.
  • What do you lose by disabling GMM publication?
    Downstream Gradle consumers fall back to the POM, losing variant fidelity, rich versions, capabilities, and constraint accuracy.

saying these in an interview costs you the question

  • Thinking you must hand-write the .module JSON — it is generated from the project's variant model.
  • Believing GMM publication is opt-in for JVM projects — it is on by default.

context

resolving links…