ADR-035: Azure-Only Maven Profile Restriction
Status
Accepted (2026-06-04)
Amended 2026-06-04: the first draft specified "unset = no profile filter". For these profile-gated poms an unfiltered build produces no provider JAR, so the default became core,azure.
Context
- Forked OSDU services carry one Maven profile per cloud provider (Azure, AWS, IBM, GC), built via the standard Java/Maven architecture (ADR-025). SPI is Azure-only, so the other profiles are wasted CPU and irrelevant signal.
- The ten service forks share a near-uniform layout: no default
<modules>, acoreprofile markedactiveByDefault, and one profile per provider. Maven deactivates anactiveByDefaultprofile as soon as any explicit-Pis passed, so-P azurealone dropscoreand the Azure module fails to resolve<svc>-core. The Azure build needs-P core,azure. - Two forks deviate:
entitlementsbuilds atprovider/entitlements-v2-azure, andindexer-queuehas no provider profiles at all (providers live in the default<modules>). These need a per-fork override.
Decision
- CI builds with a hardcoded default of
core,azure, correct for nine of the ten forks with no per-fork configuration. MAVEN_PROFILEis an optional per-service repository variable. When set it overrides the default; when unset CI usescore,azure.cascade.ymlpasses${{ vars.MAVEN_PROFILE || 'core,azure' }};validate.ymluses the same expression except on a filter-modefork_upstream, where it buildscoreonly because the generated tree has no Azure module (ADR-038).- The build always passes a non-empty
-Pvalue; it never emits a bare-P.
Consequences
- Positive:
- Fewer modules built per CI run, and unit-test results limited to code SPI ships.
- Nine of ten forks build correctly with no variable set; the override handles the rest without a template edit.
- Negative:
- No signal on whether upstream changes break the other providers. Acceptable because SPI does not ship them.
- A fork that deviates from the common pom layout builds the wrong module set until its
MAVEN_PROFILEoverride is set. This is caught on the fork's first build.
Alternatives Considered
- Continue building all provider profiles in every CI run: rejected, higher runtime and cost for signal nobody consumes.