build: don’t specify ksp version

[sdelamo]

No description provided.

[timyates]

This gives us a warning in Gradle

The Kotlin Gradle plugin was loaded multiple times in different subprojects, which is not supported and may break the build.
This might happen in subprojects that apply the Kotlin plugins with the Gradle 'plugins { ... }' DSL if they specify explicit versions, even if the versions are equal.
Please add the Kotlin plugin to the common parent project or the root project, then remove the versions in the subprojects.
If the parent project does not need the plugin, add 'apply false' to the plugin line.
See: https://docs.gradle.org/current/userguide/plugins.html#sec:subprojects_plugins_dsl
The Kotlin plugin was loaded in the following projects: ':micronaut-docs-examples:micronaut-example-kotlin', ':test-suite-kotlin-kapt-client-generator', ':test-suite-kotlin-ksp-client-generator'

I will work on a fix

[timyates]

Removed the Gradle warning with 04bd69f

Pinging @melix to make sure I've not made things worse 🤔

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

[melix]

I don't understand this change, can you give more context? The plugin shouldn't be applied to the root project, even with apply(false). Worst case it should be on the plugin classpath via the buildSrc project.

[timyates]

I believe we are trying to use the version from Micronaut-core's managed catalog instead of each project using their own version... But I don't believe we can get this in buildSrc 🤔

[timyates]

Marking as requires changes while we work out what those changes are

[melix]

mmm, right, I see why we'd like to do this, I don't think this is the right solution. We shouldn't start reintroducing specific changes to the root build for this, since we're going to deviate from the template. The fact that we have test projects using KSP is understandable, but not a good reason to do this.

Should we want to manage the KSP plugin version in the Micronaut catalog, then let's manage the KSP version of the plugin in the micronaut catalog by introducing a [plugins] block in the Micronaut catalog first. Then you'd be able to use alias(mn.plugins.kotlin.ksp) in the test project without having to tweak the root project.

[sdelamo]

I believe we are trying to use the version from Micronaut-core's managed catalog instead of each project using their own version... But I don't believe we can get this in buildSrc 🤔

Yes, I don't want the KSP version being defined in 7 modules when we already define a managed version in core.

[timyates]

@melix Are [plugin] entries propagated? I've tried

[plugins]
managed-ksp = { id = "com.google.devtools.ksp", version.ref = "managed-ksp" }

And

[plugins]
ksp = { id = "com.google.devtools.ksp", version.ref = "managed-ksp" }

But neither seem to end up in the core-bom catalog toml 🤔

[melix]

Sorry I wasn't clear @timyates , I'm not saying that this is possible already, just that this is what we should probably do, which involves changes in micronaut-build.

[sdelamo]

Sorry I wasn't clear @timyates , I'm not saying that this is possible already, just that this is what we should probably do, which involves changes in micronaut-build.

@timyates can you coordinate with @melix to do those changes to micronaut-build. We need to avoid having to define KSP versions defined in multiple modules.

[timyates]

Ok, so the changes required for build are in v6.7.0 of the shared plugin... Once we release v4.4.0 of core and migrate this to it, we will be able to use the managed plugins in core to alias the build plugins for kotlin

https://github.com/micronaut-projects/micronaut-build/releases/tag/v6.7.0
micronaut-projects/micronaut-core#10610

So I don't think we should do this PR until we are releasing against a 4.4.0 version of core. Until then we should stick with defining the plugins and versions here

[altro3]

Close it. Continue here: #1532