Hi, I'd like to reuse some code fro my `build.grad...

# gradle

[louiscad]

Hi, I'd like to reuse some code fro my build.gradle.kts files in a multi-modules project using buildSrc, but this code relies on some gradle plugins like Kotlin multiplatform and maven publish.
How can I access those in the Kotlin sources of the buildSrc? Thanks for your help!

[snowe]

you simply depend on them as dependencies in your buildSrc/build.gradle.kts and then you can access them in your code.

[louiscad]

Using the dependencies block?

[snowe]

see this project for examples. https://github.com/nebula-plugins/nebula-publishing-plugin/blob/master/src/main/groovy/nebula/plugin/publishing/maven/MavenNebulaPublishPlugin.groovy

[snowe]

that file kinda shows how you can do it.

[louiscad]

This file is groovy and has nothing to do with buildSrc as far as I can see… so "kinda" is accurate 😅

[snowe]

buildSrc is just a plugin. You can implement it in groovy, kotlin, java, Scala, it doesn't matter.

[snowe]

If you were to copy that entire project into a buildSrc folder it would work.

[louiscad]

Alright, adding the following into my `buildSrc`'s build.gradle.kts file helped:

repositories {
    google()
    jcenter()
    gradlePluginPortal()
}
dependencies {
    implementation("com.android.tools.build:gradle:3.3.1")
    implementation("org.jetbrains.kotlin:kotlin-gradle-plugin:1.3.21")
}

Also, I realized I do not need to use the plugin ids I'd use in the plugins DSL, but only what I usually put in the `builscript`'s dependencies using the classpath configuration (but using the implementation configuration here).

Thanks for the hints, it was helpful!

[gildor]

Yes, for now you have to use maven dependency id, but there is a feature request to allow use plugin id for dependencies of other plugins

[gildor]

https://github.com/gradle/kotlin-dsl/issues/430

[gildor]

buildSrc is just a plugin

To be morr correct "buildSrc" is not a plugin itself. It's just a JVM module that will be added to your project's gradle classpath. But because everything in buildSrc becomes part of build config classpath you also can add any dependencies to it, including third party or own plugins and they will be available to application to your own modules

[snowe]

Hm. that distinction seems weird. Can you not just turn a buildSrc folder into a plugin directly? You can even reference it with a plugin id.

[gildor]

No, code inside of buldSrc is not a Gradle plugin

[gildor]

Just a code that compiled and available for your build config

[gildor]

You cannot reference code in buildSrc by plugin id without explicit usage of binary plugin or precompilee plugin

[louiscad]

Not sure how that applies to maven-publish though, the technique I mentioned above doesn't work because I don't know the dependency I should add nor the version

[gildor]

Not sure what you mean and how this related to maven publish

[gildor]

You just can consume any Gradle plugin as regular dependency in your buildSrc

[gildor]

For now to do that you can use plugin published to any generic maven repo (including kotlin), or you can use workaround mentioned in this issue that allows consume any Gradle plugin published on Gradle plugins portal

[louiscad]

I wanted to use the publishing { … } extension for Project with no luck, but it seems to only affect accessors, I can access the types from the maven-publish plugin.

[gildor]

But why do you need publishing extension in buildSrc?

[gildor]

Just to provide common config?

[gildor]

maven-publish is core plugin, so you don't need any additional dependencies

[gildor]

Also you cannot use static accessors in this case, because static accessors work only when you apply plugin, but for some common configuration you have to listen when project applied some plugin and configure it, but you cannot use static accessors for it

[gildor]

But if apply kotlin-dsl plugin to your buildSrc, you will have access to some non-generated helper methods of kotlin-dsl

[snowe]

@gildor you can use a plugin id, as referenced in the documentation. https://guides.gradle.org/writing-gradle-plugins/#declare_a_plugin_identifier

[snowe]

I would know because I wrote a buildSrc plugin, and converted it straight into a regular gradle plugin by just copying it into its own directory...

[louiscad]

@gildor Yes it's to provide common config for a 40+ modules library. So it's because these generated static accessors are not buildSrc compatible. A bit weird to have this inconsistency, don't you think?

[gildor]

@snowe But you wrote plugin! But not every code in buildSrc should be Gradle plugin, it may be any code, and buildSrc is not plugin itself. And as I mentioned above you can write plugin in buildSrc but only explicitly, buildSrc is just a JVM module

[gildor]

@louiscad it's exactly the same situation if you write a Gradle plugin, you don't have static accessors. Maybe it may be somehow improved in future, but even now you must apply plugin using plugins DSL if you need access to static accessors and this is special mechanism, not just adding plugin to classpath

[snowe]

@gildor ah, I misunderstood. I don't think I've ever seen buildSrc without being a plugin. What other kind of code would you put in it?

[gildor]

Most common use case is just some helper class or function (including a config for some plugin that may be applied manually, without plugin) , even custom task, also now many projects move versions and dependencies to object in buildStr
Neither from mentioned use cases require plugin creation or plugin application, you just have access to all classes in all your modules

[snowe]

why wouldn't you just use a gradle script then. you'd avoid all the trouble of buildSrc, and still have things separated.

[gildor]

Because with Kotlin DSL usage would be really hard, you don't have auto complete, everything is dynamic
Also you have to include script plugin, but build src code already available

[gildor]

Even in official Kotlin DSL guide usage of buildSrc is preferable over script plugins

[gildor]

Check for example this sample from kotlin-dsl repo
https://github.com/gradle/kotlin-dsl/blob/master/samples/multi-project-with-buildSrc/buildSrc/src/main/kotlin/HelloTask.kt

[snowe]

Hmm. I thought you had to include buildSrc as well, I'm guessing that's just for plugins then.

[gildor]

As you can see there is no plugins

[snowe]

and yeah I still write my build scripts in groovy.

[gildor]

You can write build scripts in groovy, but nothing prevents you from using Kotlin in buildSrc

[gildor]

had to include buildSrc as well

buildScr included by default, but if you have plugin in buildSrc you have to apply it same as any other plugin

[snowe]

yes, that's what I mean.

[gildor]

What is your usual use case for plugin in buildSrc? To apply some configs?

[snowe]

testing a plugin before extracting it out. I find almost no use for buildSrc otherwise.

[gildor]

Maybe with groovy, when you don't have static checks and code completion this is like that