rule exceptions possible?

[nkiesel]

I right now have multiple rules for Jackson, among them one for jackson-core:

com.fasterxml.jackson.core:*
              ^^^^^^^.^^^^

resulting in

com.fasterxml.jackson.core:jackson-databind:{require 2.13.2; reject _} -> 2.13.2
com.fasterxml.jackson.core:jackson-core:{require 2.13.2; reject _} -> 2.13.2
com.fasterxml.jackson.core:jackson-annotations:{require 2.13.2; reject _} -> 2.13.2

I now want to change just jackson-databind to 2.13.2.2. I tried to add

com.fasterxml.jackson-core:jackson.databind:*
                           ^^^^^^^.^^^^^^^^

to my rules file and version.jackson.databind=2.13.2.2 to versions.properties but that failed with "At most one column character (':') is allowed" error. I then removed the last :, but my "jackson-databind" version is not used. Is that fixable, or do I have to remove the
com.fasterxml.jackson.core:* (which would result in multiple repetitions in versions.properties)?

[jmfayard]

You could simply use the hardcoded version com.fasterxml.jackson.core:jackson-databind:2.13.2.2 in your Gradle Build file. That always takes precedence over whatever refreshVersions is doing.

[nkiesel]

Understood. I'm using Libs.kt in buildSrc (from the 0.7.0 version I'm trying to upgrade from), so I can code it there centrally (this is a multi-module setup with 20+ modules). But of course, I will then loose out on the version upgrades. And the bigger problem is how to prevent my team from abusing this "escape hatch" to hard-code their currently desired dependencies.

[nkiesel]

Also - and this might be the biggest concern -: once I hard-code the version number in Libs.kt, I will loose the "inform me about possible upgrades" feature for this dependency.

[imashnake0]

refreshVersions does exactly that tho. 🤔