You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The other way around, if you want the jOOQ plugin to pull in the same version of jOOQ as defined by the Spring Boot plugin, you have to explicitly set jooq.version = dependencyManagement.importedProperties['jooq.version'].
I believe this is not really the case. Two things are conflated here: Spring Boot plugin, and Spring Dependency Management Plugin. The first one is basically mandatory for any reasonable SB app, the other is an outdated plugin that is considered deprecated and was needed before Gradle got platform handling to handle BOMs. The suggested way works only if SDMP is included, because it forces jOOQ plugin to use the version defined by SDMP - not the Spring Boot plugin!. It fails on an up-to-date config with platforms and without SDMP, because no dependencyManagement var exists then etc.
Also, there is no need for "the jOOQ plugin to pull in the same version of jOOQ" as defined elsewhere (e.g. by Spring components). Gradle will, by default, keep using the version defined elsewhere. It's enough to tell the jOOQ plugin to stop overriding the default, because the constraint from the plugin will win over the other version request when Gradle does the dep resolution if it's not prevented.
As a result, I do believe that simply setting jooq.version = "" does the trick - since Gradle will then require an explicit version elsewhere and match the requirement for the library to it, it will just handle it like the usual platform-based version-less specifiers.(at least that was the case for me). It also works for a setup with SDMP - the dep from jOOQ plugin would be version-less, and, as a result, the version constraint from SDMP would be applied.
tl;dr jooq.version = "" gives you the perfect
+--- org.jooq:jooq -> 3.19.16 (*)
on both SDMP-based and SDMP-less builds. I thus propose to update the readme accordingly, i.e.
The other way around, if you want the jOOQ plugin to not affect the version of jOOQ already defined by any other dependency source (e.g. Spring Boot BOMs or Spring Dependency Management plugin), you have to explicitly set jooq.version = "".
I can even do the PR myself :D
The text was updated successfully, but these errors were encountered:
The readme suggests this:
I believe this is not really the case. Two things are conflated here: Spring Boot plugin, and Spring Dependency Management Plugin. The first one is basically mandatory for any reasonable SB app, the other is an outdated plugin that is considered deprecated and was needed before Gradle got
platform
handling to handle BOMs. The suggested way works only if SDMP is included, because it forces jOOQ plugin to use the version defined by SDMP - not the Spring Boot plugin!. It fails on an up-to-date config withplatform
s and without SDMP, because nodependencyManagement
var exists then etc.Also, there is no need for "the jOOQ plugin to pull in the same version of jOOQ" as defined elsewhere (e.g. by Spring components). Gradle will, by default, keep using the version defined elsewhere. It's enough to tell the jOOQ plugin to stop overriding the default, because the constraint from the plugin will win over the other version request when Gradle does the dep resolution if it's not prevented.
As a result, I do believe that simply setting
jooq.version = ""
does the trick - since Gradle will then require an explicit version elsewhere and match the requirement for the library to it, it will just handle it like the usual platform-based version-less specifiers.(at least that was the case for me). It also works for a setup with SDMP - the dep from jOOQ plugin would be version-less, and, as a result, the version constraint from SDMP would be applied.tl;dr
jooq.version = ""
gives you the perfecton both SDMP-based and SDMP-less builds. I thus propose to update the readme accordingly, i.e.
I can even do the PR myself :D
The text was updated successfully, but these errors were encountered: