gviedma opened a new issue, #12676:
URL: https://github.com/apache/pinot/issues/12676
# Problem Statement
Pinot’s approach to dependency management can be ad-hoc and inconsistent,
with dependency versions being resolved in multiple different ways:
1. Explicit versions defined in dependencyManagement section in the root pom
a. Sometimes these are defined using a property, sometimes the version
is hard-coded
2. Submodules may define their own version of a dependency
a. Again these may be hard-coded or defined in a property
3. No explicit version is set, in which case Maven resolves the version by
analyzing transitive dependencies
The lack of consistency results in the following problems:
1. Unintended or unpredictable dependency version changes. Bumping one
library can have an unforeseen ripple effect on the version of other transitive
dependencies.
2. Wasted effort, as contributors are each trying to solve dependency
management in their own way.
3. Lack of centralized dependency management means it is not possible to
override a particular dependency version without being subject to regressions
caused by subsequent OSS changes. As a result, platforms that need to build
Pinot with well-known dependency versions for compliance reasons have to
frequently fix their builds to stay aligned with OSS dependency management
changes.
# Proposal
Ideally, Pinot should leverage Maven’s best practices for Dependency
Management. At a high level, this consists of standardizing along the following
areas:
1. All explicit dependency versions should be defined in the parent pom via
Maven’s standard
[dependencyManagement](https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management)
mechanism, and use an
[overridable](https://www.mojohaus.org/versions/versions-maven-plugin/set-property-mojo.html)
Maven property
2. Where possible, define dependencies using the Bill of Materials (BOM)
such that all related artifacts are guaranteed to be at the same version.
3. Do not set any explicit dependency versions at a submodule level.
Instead, these should always be set as described in 1).
We should also consider enforcing the above recommendation via a linting
mechanism to ensure consistency.
## Example of How to Specify a Dependency Version
For example, do not do this in a submodule:
```
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-context</artifactId>
<version>1.60.1</version>
</dependency>
```
Instead, follow this pattern in the root pom:
```
<!-- pinot/pom.xml -->
<properties>
<grpc.version>1.60.1</grpc.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-bom</artifactId>
<version>${grpc.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@pinot.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@pinot.apache.org
For additional commands, e-mail: commits-h...@pinot.apache.org
