Make flyway and jooq versions configurable.

[victorlopezsalazar]

Hi, it would be great if the versions of the flyway and jooq plugins could be taken from either:

• Configuration properties in the gradle.properties file.
• From the declared plugins in the plugins, pluginManagement or buildscript blocks.
• Letting them be handled by a dependency manager (like the spring.dependency-management plugin or via the pluginManagement.

What do you think?

[adrianskrobaczrevolut]

Hey @victorlopezsalazar 🙂
That's actually interesting topic 🙂 Let me break it down into two points

1. The flyway itself doesn't need to be necessarily inlined with what you use in production code, it's supposed to be for the internal use of the plugin only. Although if you faced some errors with this let me know 🙂
2. The jOOQ version indeed is dependant on what you use in production code and as you always want the same version to be used by plugin and your production code, so probably everyone does something like this:

buildscript {
    val jooqVersion: String by project
    configurations.classpath {
        resolutionStrategy {
            setForcedModules("org.jooq:jooq-codegen:$jooqVersion")
        }
    }
}

That being said it might be actually a good idea to somehow inline the version with what is in the classpath. Though I'd have to investigate a little bit what are the options Gradle gives us to achieve this 🤔

[victorlopezsalazar]

Thanks for the tip on how to force a particular jOOQ version @adrianskrobaczrevolut 🙂. Indeed it would be awesome if we could follow a more integrated way of specifying the version for jooq and flyway. For the latter, unfortunately support for targeting mysql 5.6 was moved to the flyway enterprise version and changing to 5.7 poses some compatibility problems with either the mysql base image configuration or the sql used in the migration scripts which can't be easily changed.

[adrianskrobaczrevolut]

hmm I see 🤔 I'm not very familiar with how flyway manages theirs paid versions of libs, but I can see that they have separate GAV coordinates, though I'm not sure if the code itself have different package names as well. If the package names are the same you could try dependency substitution(you probabbly need to add flyway repo to the build script repositories):

buildscript {
    val jooqVersion: String by project
    val flywayVersion: String by project
    configurations.classpath {
        resolutionStrategy {
            dependencySubstitution {
                substitute(module("org.flywaydb:flyway-core"))
                        .with(module("org.flywaydb.enterprise:flyway-core:$flywayVersion"))
            }
            setForcedModules("org.jooq:jooq-codegen:$jooqVersion")
        }
    }
}

Could you try this and let me know if that does the job? That would be some starting point to think about how to approach it better 🙂

[victorlopezsalazar]

Sorry, it took me a bit to have some time to test this. Your approach works nicely. For my particular case I had to replace the flyway version to:

            dependencySubstitution {
                substitute(module("org.flywaydb:flyway-core"))
                        .with(module("org.flywaydb:flyway-core:5.2.4"))
            }

After this change the jOOQ classes were generated using a docker image for a 5.6 mysql database without issues.

As suggested, it would be really nice if that configuration could be taken from gradle.properties or using some dependency manager 🙂 .

Thanks!

[adrianskrobaczrevolut]

Thank you for confirming 👍 I'll try to figure out some neat way to make the setup more user friendly. Gonna keep update you here once done 🙂

By the way if you need to just change the version then you can use setForceModules the same as for jooq-codegen dependency 🙂