Consider manging Flyway Gradle plugin

[ciscoo]

The Maven plugin is currently managed:

spring-boot/spring-boot-project/spring-boot-dependencies/build.gradle

Line 388 in 32433e8

"flyway-maven-plugin"

A bit ugly, but one could then do:

// buildSrc/build.gradle.kts
dependencies {
    implementation(platform("org.springframework.boot:spring-boot-dependencies:3.4.0"))
    implementation("gradle.plugin.org.flywaydb:gradle-plugin-publishing")
}

// build.gradle.kts
plugins {
    id("org.flywaydb.flyway")
}

Granted this will manage other dependencies, but at least the Flyway plugin will align with the version that Boot manages.

Ref: https://stackoverflow.com/questions/79215364/how-to-use-spring-boot-bom-to-manage-flyway-plugin-version-in-gradle

[wilkinsona]

Thanks for the suggestion.

We manage the Maven plugin already because Maven has the concept of plugin management. Prior to the introduction of version catalogs, Gradle didn't have an equivalent concept. We don't publish a version catalog at the moment and I'm a little reluctant to manage Flyway's Gradle plugin as a "normal" dependency as it would then, arguably, be in the wrong place.

#37836 is tracking providing plugin management for Gradle projects. In the meantime, building on your example above, you can use a ComponentMetadataRule to align the plugin's version with the constraints already declared in spring-boot-dependencies:

dependencies {
	components {
		all(FlywayAlignmentRule)
	}
	implementation(platform("org.springframework.boot:spring-boot-dependencies:3.4.0"))
	implementation("gradle.plugin.org.flywaydb:gradle-plugin-publishing:10.0.0") // Any older, existing version
}

abstract class FlywayAlignmentRule implements ComponentMetadataRule {

	void execute(ComponentMetadataContext context) {
		context.details.with {
			if (id.group.startsWith("org.flywaydb") || id.group.startsWith("gradle.plugin.org.flywaydb")) {
				belongsTo("org.flywaydb:flyway-virtual-platform:${id.version}")
			}
		}
	}

}

The above will result in the plugin's version being 10.20.1.

Please use this workaround for now. I think it's preferable to managing Gradle plugin's as "normal" dependencies which we'd then need to undo when we tackle #37836.

[vpavic]

I don't think that managing Gradle plugins as regular dependencies should be dismissed so easily, or that #37836 will remove the need/value of it, because there are different ways of structuring Gradle projects and consequently declaring dependencies to Gradle plugins.

For example, it's quite common to declare dependencies to 3rd party Gradle plugins only in included builds and then have those builds provide convention plugins that are the only thing plugins DSL is used for. See jjohannes/idiomatic-gradle as an example of project structured in such a way. In that case Gradle plugins really are just a regular dependencies.

[wilkinsona]

In terms of their dependency management, and the scope of spring-boot-dependencies, I don't think it would be wise to treat Gradle plugins as regular dependencies. As @ciscoo has noted above, using spring-boot-dependencies will manage other dependencies. In the context of a project's Gradle plugins, that dependency management is likely to be far too broad and may lead to unexpected incompatibilities.

I'm not against offering some management for plugin versions, but I think it should be done in such a way that the management can be applied in a more focussed manner than would be possible if they're part of spring-boot-dependencies.

[vpavic]

using spring-boot-dependencies will manage other dependencies

That's actually what I already use and rely on in my included builds, because like any other project included build also needs testing and possibly some other commons libraries so it's reasonable to have those aligned with the ones used in the rest of the codebase. By doing so I'm not seeing any special dependency management challenges.

Aligning dependency versions of Gradle plugins that are accompanying something that Spring Boot provides auto-configuration for (like Flyway, jOOQ and some others) is frequent source of frustration especially since it feels that a very small change on Spring Boot's side could make things a lot easier (for at least some of the users).

I really don't see the risks of doing what @ciscoo requested here, at least for libraries that publish their Gradle plugins together with the main artifacts so there's no overhead from dependency management perspective (same version). When #37836 is resolved both options will still have their audience, depending on the approach given project takes to manage Gradle plugins (plugins DSL vs included build).

[wilkinsona]

My main concern is with the expectation that will be set if we start managing Gradle plugins in spring-boot-dependencies.

We've seen incompatibilities on the Gradle plugin classpath in the past caused by dependencies of Boot's Gradle plugin. Commons Compress is one that immediately comes to mind. If we expand that to everything that's managed by spring-boot-dependencies, the potential for incompatibilities increases considerably and that's a risk that I'm not (yet?) prepared to take. Maintaining compatibility in spring-boot-dependencies is already hard enough without broadening its scope.

there's no overhead from dependency management perspective (same version)

If you want to use spring-boot-dependencies to manage a plugin that has the same version as the rest of the library, it is possible today as shown above with the ComponentMetadataRule trick. This is undoubtedly a little bit cumbersome but I feel it's at an acceptable level as it shows that it's possible without setting expectations too high for version compatibility on the plugin classpath.

In short, I definitely hear you with the need for some plugin version management, but I don't want to rush into a spring-boot-dependencies-based approach as I think we're likely to regret using a sledgehammer to crack this particular nut.