This message was deleted.

You could for example have the user apply the boot plugin and then in your plugin behave according to the version that is applied.

but Is there a way to dynamically apply the boot version used in the convention plugin when applying the plugin?

Besides letting the user applying the boot plugin as mentioned, the user could use normal version management things like a version constraint, eventually with a strict version when downgrading, and so on to control which boot plugin verison will be on the buildscript class path.

convention-plugin-project • src/main/kotlin ◦ co.test.gradle.java-convention.gradle.kts ◦ co.test.gradle.nexus-convention.gradle.kts ◦ co.test.gradle.spring-app-convention.gradle.kts • build.gradle.kts

dependencies {
    implementation(plugin(libs.plugins.spring.boot))
    implementation(plugin(libs.plugins.spring.dependency.management))
}

• gradle ◦ libs.version.toml (spring boot version) The my project is structured like this. When using the project by publishing it on nexus Even if someone only want to use nexus-convention, there is an inconvenience in that boot dependency is included in the client. However, it is cumbersome to configure all gradle.kts into each project. What solutions can we consider?

As a first point, not related to your actual question, you should stop using the Spring dependency management plugin. It is an obsolete relict from times when Gradle did not have built-in BOM support and by now does more harm than good. Even its maintainer recommends not to use it anymore, but using the built-in BOM support with

platform(...)

. Regarding the question, what is the problem with the dependency being in the plugin. Does the consumer only wanting nexus convention use spring boot plugin, but wants a different version, or does he not want to use it at all? If he does not want to use it at all, there should be no harm. If he does want to use a different version, either he can mitigate the issue by controlling the version, or you can mitigate the issue by either indeed splitting the plugins in multiple convention plugin projects, or you can mitigate it by just having spring boot plugin as

compileOnly

but then consumers that do want to have spring boot need to provide the dependency themselves. You could for example also make your convention plugin not apply the plugin at all, but just react to it being applied, so that consumers always need to apply the spring boot plugin themselves, but then get the configuration from your convention plugin.

I agree with the advice not to use the Spring dependency management plugin. I will keep this in mind.

I'm not sure what you mean with "1". But yes, one option is that the user applies the spring boot plugin himself, as I wrote above. That would also be the easiest way to "provide that dependency".

Thank you I have one more question. How do I split a plugin from a convention plugin project? Do you mean separating each convention plugin into a separate project or module?

Not necessarily each, but at least into one that handles spring boot and has the dependency and one that does the rest. Or one for each if you have the same "issue" with other dependencies. But yes, just make the convention plugin project a multi-project build, or if you prefer have different builds, shouldn't make much difference.

Thank you for your reply.