This message was deleted.
# community-support
s
This message was deleted.
t
Yes. Checkstyle depends on Guava, but also transitively on plexus-container-default which depends on the ancient Google Collections. Use a capability resolution rule to select Guava (and report the issue to Checkstyle; unless they already have an exclusion in their POM that Gradle does not respect, in that case file a bug against Gradle)
c
should I select the latest? or you don't know
what's also interesting... it looks like I set my version of checkstyle to 8.+ so gradle is overriding it?
c
you should prefer Google Guava over the Very Ancient Google Collections - and, as noted above, vanquish that legacy library from the dependency graph.
c
I'm guessing I can't use static accessors
v
Just because I stumbled upon it, you should change
dependsOn(subprojects.map { it.tasks.dependencies })
to
dependsOn(subprojects.map { "${it.path}:dependencies" })
to not reach into those other projects model.
c
Copy code
configurations.checkstyle {
  resolutionStrategy.capabilitiesResolution.withCapability("com.google.guava:guava") {
    selectHighestVersion()
  }
}

dependencies {
  checkstyle(libs.checkstyle)
}
didn't work πŸ˜•
c
it isn’t the highest version - you want to match on the capability
com.google.collections:google-collections
(from the build scan) and select the Guava module.
c
Copy code
configurations.checkstyle {
  resolutionStrategy.capabilitiesResolution.withCapability("com.google.collections:google-collections") {
    select("com.google.guava:guava")
  }
}
Copy code
> Could not resolve all dependencies for configuration ':app:checkstyle'.
   > Capability resolution rule failed with an error
      > Invalid module component notation: com.google.guava:guava : must be a valid 3 part identifier, eg.: org.gradle:gradle:1.0
so I have to provide the version? I can't say use the version that's being asked for?
t
See the sample code for log4j-over-slf4j in the docs (link above) and adapt it for Guava and Google Collections.
v
Were the versions increasing across the rename? Then just
selectHighestVersion()
should be fine. It means select the higher version of the two conflicting ones.
Yes, the old one was up to 1.0 and the new one started with 10.0, so
selectHighestVersion()
should be it here
c
ok, I decided to test it, this exists purely because gradle decided to ignore the version of checkstyle I put in my libs.versions.toml and upgrade me to version 10
and so if I remove my version from dependencies, that fixes this
is that a bug?
like why did it stop using version 8
v
Where do you tell it to use 8?
c
Copy code
dependencies {
  checkstyle(libs.checkstyle)
}
Copy code
checkstyle = "com.puppycrawl.tools:checkstyle:[8,)"
oh, that's 8 or later πŸ˜•
I think
v
Yes
c
sigh got it
ok, maybe I just let gradle manage that now πŸ˜•
idk
trying to avoid upgrade hell on it, and I'm not sure what the best way to do that is
v
Besides that, from a quick look you only configure the checkstyle version on the root project, but where it complains is on
app
πŸ€” 1
I don't think the root project configuration is relevant here
I guess if you do the configuration on the correct project it should maybe work
c
seems to work on sub projects...
...
I'm always open to improvements
v
Well, you can always just use the respective
dependencies
task for the
checkstyle
configuration or a build
--scan
to see which will be used.