Hello, hope you are doing good. Does anybody knows if this is possible to share Kotlin code between ...

# gradle

[Loïc Lamarque]

Hello, hope you are doing good.
Does anybody knows if this is possible to share Kotlin code between build scripts and settings script ?
For instance, I would like to share an enum of subprojects.

// In file 'Subproject.kt'
fun Settings.include(subproject: Subproject): Unit = include("$subproject")
fun DependencyHandler.project(subproject: Subproject): ProjectDependency = project(":$subproject")
enum class Subproject {
    First,
    Second;

    override fun toString(): String = name.lowercase()
}

// In file 'settings.gradle.kts'
include(Subproject.First)
include(Subproject.Second)

// In file 'second/build.gradle.kts'
dependencies { implementation(project(Subproject.First)) }

[Javier]

you can use buildSrc for that

[Javier]

buy I would enable enableFeaturePreview("TYPESAFE_PROJECT_ACCESSORS") so you can just do

implementation(projects.subproject.first)

[Vampire]

No he cannot, unless he uses a really ancient version of Gradle.
buildSrc is not build before the settings script execution, but after.

You can though have code in a project you add to the settings classpath either in the buildscript block or via a (possibly no-action) settings plugin that you apply, that can also come from an included build. Then those classes would also be available in the build scripts.

But I agree with Javier that it might make much more sense to enable the project accessors instead.

[Loïc Lamarque]

Interesting, thank you @Javier. I will check the type-safe project accessors.
@Vampire Does the shared classes would be available in the settings script while using a settings plugin?
By the way, I'm still using Gradle 7.5. 🙃

[Vampire]

That's not ancient enough for using buildSrc in settings script. 🙂

[Vampire]

Yes, if the classes are part of the jar of a settings plugin, then you can use the classes in the settings script, as long as the plugin jar is added to the settings script classpath, which easiest is achieved by applying it.

[Loïc Lamarque]

@Vampire Do you have any resource on that topic please? I will make further research on that for learning how to do it. Because I tried to use code from the buildSrc in the settings script, but Gradle couldn't resolve it...

[Vampire]

On which topic? I'm unsure what you want to have. As for buildSrc I said you cannot use anything from there in the settings script unless you are on an ancient Gradle version.

[Loïc Lamarque]

@Vampire Ah! So should I focus on creating a settings plugin for doing so?

[Vampire]

That's what I said, yes. A settings plugin that does no action is the easiest way to get code onto the settings classpath, especially if it is not a published artifact but coming from an included build.

[Loïc Lamarque]

@Vampire What do you mean about "plugin that does no action"?

[Javier]

an empty plugin implementation that the apply function does nothing

[Loïc Lamarque]

Oh okay thank you @Javier.
There is still something that I don't understand in the process: where should I put shareable code in the settings plugin if it does nothing?

[Vampire]

Just in the same source set as the plugin. The plugin is just an easy way to bring the classes onto the class path

[Loïc Lamarque]

@Vampire Simple as that?! 😮
I will try this out. Thank you for your time and consideration!