skip to content

Compare aligning a family via a virtual platform (belongsTo rule) versus a published java-platform BOM. When would you pick each?

level: seniorimportance: should knowfreq 30%

answer

  1. virtual = local rule, no artifact
  2. published = shareable versioned artifact
  3. convention plugin scales virtual rules
  4. platform supplies versions; rule only aligns
  5. org governance → publish platform

basics

~20 s

Virtual platform (belongsTo rule) needs no publishing and aligns even families that shipped no BOM, but lives in each build. A published java-platform is shareable and versioned across many repos but you must author and release it.

solid answer

~50 s

Both give one consistent family version, but differ in *ownership and reach*. A **virtual platform** is a `ComponentMetadataRule` calling `belongsTo("g:vp:${version}", true)`; Gradle synthesizes the platform during resolution. Pros: works for any family even without a vendor BOM, aligns across groups, needs no extra artifact. Cons: the rule is local — every consuming build must declare it (or inherit it via a convention plugin), and it only aligns, it doesn't *recommend* a version. A **published java-platform** is a real artifact (constraints under the `java-platform` plugin, published with `maven-publish`). Pros: one versioned source of truth shareable across the org, can supply default versions, supports `enforcedPlatform`. Cons: someone must author, version, and release it; updates need a new platform release. Rule of thumb: vendor ships a BOM → use it; no BOM but you control all builds → convention-plugin virtual rule; many independent repos need one governed version → publish a java-platform.

go deeper

for a junior

Know both exist and that one is published while the other is a local rule.

for a middle

List concrete pros/cons and give the basic decision rule (BOM exists vs not).

for a senior

Reason about reach, convention-plugin distribution, and combining mechanisms.

for a principal

Own the org strategy: when to mandate a published platform vs allow tactical virtual rules; define governance and release cadence.

## Two mechanisms, same goal Both ensure a family resolves to one version, but they sit at different points in the dependency-management toolbox. ### Virtual platform via metadata rule ```kotlin abstract class FamilyAlignRule : ComponentMetadataRule { override fun execute(ctx: ComponentMetadataContext) = ctx.details.run { if (id.group == "com.example.lib") belongsTo("com.example.lib:lib-platform:${id.version}", true) } } ``` - **No artifact** — Gradle invents the platform at resolution time. - **Best when** the vendor never published a BOM, or you need to align across multiple groups, or you can't change the upstream metadata. - **Reach** is whatever builds register the rule. To scale it, ship it in a **convention plugin** so every project applies it uniformly. - It only *aligns*; it doesn't introduce a recommended version. The winning version still comes from what's requested in the graph. ### Published java-platform ```kotlin plugins { `java-platform`; `maven-publish` } dependencies { constraints { api("com.example.lib:a:1.4"); api("com.example.lib:b:1.4") } } ``` - A **real, versioned artifact** consumers import with `platform("com.example:lib-platform:1.0")`. - It *both* supplies default versions (constraints) and, when authored to, drives alignment. - **Best when** many independent repositories must share one governed version set — the platform's own version is your audit trail. - Updating means publishing a new platform version and bumping consumers. ## Decision matrix | Situation | Pick | |---|---| | Vendor publishes a BOM/platform | Use it directly (`platform(...)`) | | No BOM, you own all builds | Virtual rule, shipped via convention plugin | | No BOM, many external/independent repos | Publish a java-platform | | Need to force-override versions org-wide | Published platform + `enforcedPlatform` | | Family spans several Maven groups | Virtual rule mapping all groups to one coord | ## Combining them They aren't exclusive: a published `java-platform` can itself be authored so its members align, and a build can apply *both* an org platform (for versions) and local metadata rules (for alignment of an oddball family the platform doesn't cover). ## Governance angle For an org, the published platform is usually the strategic choice — it's versioned, reviewable, and centrally owned. Virtual rules are tactical: quick fixes for families with no upstream BOM. Encoding either in a shared convention plugin is what keeps dozens of repos consistent without copy-paste.

  • How do you scale a virtual-platform rule across many repos without copy-paste?
    Put the ComponentMetadataRule in a shared convention/settings plugin that every project applies, so registration is inherited centrally.
  • Can a published java-platform also perform alignment?
    Yes — it can carry constraints that supply versions and be authored so its members move together; alignment and version recommendation aren't mutually exclusive.
  • Why might a virtual platform be the only option for some families?
    When the vendor publishes no BOM and you can't modify upstream metadata, synthesizing a virtual platform locally is the only way to force lockstep.

saying these in an interview costs you the question

  • Claiming a virtual platform is automatically visible to all consumers — it only applies where the rule is registered.
  • Treating published platform and virtual rule as interchangeable without considering reach/ownership.

context

resolving links…