Dashboard (and Linkage Checker's ClassPathBuilder) to take an option to resolve dependency graphs with Gradle's way.
While reading errors in #1982 (comment), I noticed that the dependency conflicts (due to picking up old library versions) do not occur to Gradle users.
Where is this affected?
The LtsCompatibilityTestRunner resolves the dependencies of the BOM:
ImmutableList<Artifact> bomManagedDependencies = bom.getManagedDependencies();
ClassPathBuilder classPathBuilder = new ClassPathBuilder();
ClassPathResult resolvedDependencies = classPathBuilder.resolve(bomManagedDependencies, false);
This resolves the dependencies in Maven's closest-win strategy. This strategy is prone to getting old dependencies which cause dependency conflicts. For Gradle users, the resolution is different; it uses highest-win strategy. Therefore, the current result shown in the pull request contain false positives and false negatives.
GradleDependencyMediation?
We already have MavenDependencyMediation. I think the implementation would be creating GradleDependencyMediation.
Dashboard (and Linkage Checker's ClassPathBuilder) to take an option to resolve dependency graphs with Gradle's way.
While reading errors in #1982 (comment), I noticed that the dependency conflicts (due to picking up old library versions) do not occur to Gradle users.
Where is this affected?
The
LtsCompatibilityTestRunnerresolves the dependencies of the BOM:This resolves the dependencies in Maven's closest-win strategy. This strategy is prone to getting old dependencies which cause dependency conflicts. For Gradle users, the resolution is different; it uses highest-win strategy. Therefore, the current result shown in the pull request contain false positives and false negatives.
GradleDependencyMediation?
We already have
MavenDependencyMediation. I think the implementation would be creating GradleDependencyMediation.