Add pinot-bom module for external consumers#18540
Open
anshul98ks123 wants to merge 2 commits into
Open
Conversation
Adds a Maven BOM (Bill of Materials) module that aggregates the
${project.version} pinning of every pinot-* artifact already declared in
the parent POM's <dependencyManagement>. External consumers (downstream
forks, integrators) can now import pinot-bom via <scope>import</scope>
and pick up every Pinot module version through a single managed entry,
instead of either inheriting from pinot's <parent> (which leaks the
consumer's ${revision} into pinot-* coordinates) or copy-pasting per-
artifact overrides each time a new pinot-* module is added.
Usage on the consumer side:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.apache.pinot</groupId>
<artifactId>pinot-bom</artifactId>
<version>1.6.0-SNAPSHOT</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
Under <scope>import</scope> Maven fully interpolates the BOM at import
time, so ${project.version} resolves to the BOM's own version, not the
importer's. The 71 existing pinot-* DM entries in the parent POM stay as
they are -- Pinot's own modules continue to inherit them via <parent>
unchanged. No functional change for the existing build.
…t publish time
Replaces the hardcoded 1.6.0-SNAPSHOT literals in every <dependencyManagement>
entry with ${project.version}, then runs flatten-maven-plugin (flattenMode=bom,
pomElements.dependencyManagement=resolve) so the published pom-bom-*.pom carries
literal resolved versions while the source POM stays version-agnostic. Future
parent-version bumps now propagate automatically without an edit to every BOM
entry.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #18540 +/- ##
============================================
- Coverage 64.27% 64.24% -0.04%
Complexity 1126 1126
============================================
Files 3311 3311
Lines 203784 203784
Branches 31720 31720
============================================
- Hits 130974 130911 -63
- Misses 62308 62371 +63
Partials 10502 10502
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue
External integrators of Apache Pinot (downstream forks, vendors, embedded users) that inherit from
org.apache.pinot:pinotvia<parent>cannot pin allpinot-*versions through a single managed entry. There is no published BOM artifact today; consumers have to either:<parent>org.apache.pinot:pinot</parent>and accept that${project.version}inside the parent's<dependencyManagement>re-interpolates against the child's effective POM (leaking the consumer's own${revision}into Pinot dep coordinates and breaking resolution against Maven Central / mirrors), or<version>${apache.pinot.version}</version>override for every newpinot-*module the parent adds.Every new module (e.g.,
pinot-sql-ddl,pinot-udf-test,pinot-materialized-view) re-breaks downstream CI until the override list catches up.The StarTree fork has hit this three times in the last five days alone — see startree-pinot#3309 (added overrides for
pinot-sql-ddl+pinot-udf-test) and startree-pinot#3338 (added an override forpinot-materialized-view, the module introduced in #18528).Fix
Add a new
pinot-bommodule that publishes a standalone Bill-of-Materials POM listing every publishedpinot-*artifact at a hardcoded literal version. Downstream consumers import it via<scope>import</scope>:The BOM uses literal versions (not
${project.version}) so the published POM does not interpolate against the importer's project. Every newpinot-*module added in subsequent releases is picked up via the BOM with no consumer-side patch required.The existing
<dependencyManagement>block in the parentpom.xmlis left untouched — Pinot's own modules continue to inherit it via<parent>exactly as before. The BOM is purely additive.Testing
pinot-bombuilds + installs locally.pinot-*dep (verified via grep).pinot-*modules unaffected (no change to their POMs or to the root reactor besides adding the new module entry).<scope>import</scope>— see companion PR startreedata/startree-pinot#3339.