Open ZacBlanco opened 4 years ago
We may want to look into using this plugin: https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two weeks if no further activity occurs. Thank you for your contributions.
@Xenorith is this still valid? otherwise help me close this please
this is a valid work to stabilize maven dependencies. we still run into this problem to this day, which has caused for CVEs being surfaced
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two weeks if no further activity occurs. Thank you for your contributions.
Is your feature request related to a problem? Please describe.
Alluxio lives as a project because we include many, many maven dependencies so we don't have to write our own code. That comes with a complexity penalty when it comes to version upgrades. Of the many projects we use, some of the dependencies share dependencies of the same project (i.e. netty as a dependency of Alluxio and gRPC, or log4j as a dependency of Alluxio and the SLF4J impl).
When upgrading it's imperative that we do our best to match dependency versions because only one jar will ever make it into the final build of the product. Otherwise, we risk some dependencies expecting versions of one project, but instead, getting another which could result in runtime exceptions. Whats worse is that which version gets picked up can simply be affected by the ordering of the modules and/or dependencies in the POM!
We need a way to ensure and explicitly define which dependencies make it into the final build of the project to do our best to prevent RuntimeExceptions due to missing classes or methods.
Describe the solution you'd like
There exists a maven plugin somewhere which should allow us to enforce conflicting dependency version be strictly
<excluded>
when added to the maven POM file. This ensures a stable build with consistent versions as specified exactly in the POM, without any changes simply due to the declaration order of the dependents.Describe alternatives you've considered
Have not considered others.
Urgency
Stable builds, medium/low
Additional context
PrestoSQL/DB has some kind of solution similar to what I suggested already in place