ben-manes
commented
2 months ago can you write it into a minimal sample project?
You might consider using jvm-dependency-conflict-resolution for common constraints, like the variant selection.
Open rynkowsg opened 2 months ago
ben-manes
commented
2 months ago can you write it into a minimal sample project?
You might consider using jvm-dependency-conflict-resolution for common constraints, like the variant selection.
rynkowsg
commented
2 months ago I made a minimal sample project here: rynkowsg/gradle-versions-plugin-i906.
rynkowsg
commented
2 months ago I'm not familiar with jvm-dependency-conflict-resolution.
Is it something you would apply to the problem shown in the minimal sample project?
ben-manes
commented
2 months ago To simplify debugging, I applied the convention plugin to all subprojects so it can be inspected individually:
allprojects {
apply(plugin = "demo.versions")
}that led to a small typo via gradle :modules:lib:jvm-library:dependencies
compileClasspath - Compile classpath for 'main'.
+--- org.jetbrains.kotlin:kotlin-stdlib:2.0.20
| \--- org.jetbrains:annotations:13.0
\--- com.google.guava:guava:33.3.0-jvm FAILEDThe individual modules seems fine in their reports
The aggregate across all projects is where it seems to combine unintentionally,
When I look at the json report, it seems like it didn't really understand that there were two versions and composed that incorrectly.
gron ./modules/lib/build/dependencyUpdates/report.json | rg guava
json.current.dependencies[0].group = "com.google.guava";
json.current.dependencies[0].name = "guava";
json.current.dependencies[0].projectUrl = "https://github.com/google/guava";
json.outdated.dependencies[10].group = "com.google.guava";
json.outdated.dependencies[10].name = "guava";
json.outdated.dependencies[10].projectUrl = "https://github.com/google/guava";So it seems like something to do with the version mapping logic, since it is atypical to have the same dependency at different versions rather than globally pin it via dependency management.
The jvm-dependency-conflict-resolution plugin is just to help avoid the flavor messiness that your convention plugin has to work around, since it would use capabilities to force a rejection when the configuration and dependency were not compatible. That didn't help your case except would have avoided you writing that logic manually.
I made a custom filter, that does two things:
You can find below the convention plugin I used to wrap entire logic related to versions selection.
Convention plugin
```kotlin import GuavaCheckResult.GUAVA_CANDIDATE_NEWER import GuavaCheckResult.GUAVA_CANDIDATE_OLDER import GuavaCheckResult.GUAVA_DIFFERENT_FLAVORS import GuavaCheckResult.GUAVA_SAME_VERSIONS import GuavaCheckResult.NOT_GUAVA import buildcfg.GradlePluginId import com.github.benmanes.gradle.versions.updates.DependencyUpdatesTask import com.github.benmanes.gradle.versions.updates.resolutionstrategy.ComponentSelectionWithCurrent import org.gradle.api.Plugin import org.gradle.api.Project import org.gradle.kotlin.dsl.withType val isDEBUG: Boolean = System.getenv("DEBUG").let { it in listOf("true", "1") }.also { println("DEBUG=$it") } fun log(message: String) { if (isDEBUG) { println(message) } } private data class VersionComparisonData( val group: String?, val module: String?, val oldVersion: String, val newVersion: String, ) class VersionsConventionPlugin : PluginI run it against my multi-module Android project and I got result that I do not expect:
If you look at the log attached HERE you will see that all calls of
rejectVersionIfwith current version33.3.0-androidand candidate version33.3.0-jre, are qualified asGUAVA_DIFFERENT_FLAVORS, therefore therejectVersionIflambda returnstrue, still at the end the plugin proposes this update.