I’m having an issue creating a plugin through `buildSrc`. The error I’m getting is the following ```...

# gradle

[rook]

I’m having an issue creating a plugin through buildSrc. The error I’m getting is the following

Could not find implementation class 'rook.bluetoothpoc.MyPlugin' for plugin 'rook.bluetoothpoc' specified in buildSrc.jar!/META-INF/gradle-plugins/rook.bluetoothpoc.properties

The path to MyPlugin is root/buildSrc/src/main/java/rook/bluetoothpoc/.

The path to rook.bluetoothpoc.properties is root/buildSrc/main/resources/META-INF/gradle-plugins/. It contains only the following line:

implementation-class=rook.bluetoothpoc.MyPlugin

I feel like I’m missing something really obvious.

[Vampire]

While it is unnecessary to maintain the file in META-INF manually if you use the right Gradle plugins, do you maybe miss the package declaration in your plugin class?

[rook]

Thanks for the quick reply, here’s the contents of MyPlugin.kt

Untitled

[rook]

build.gradle.kts

[Vampire]

Ah, wait, you have a Kotlin file in src/main/java, that's probably your problem. It should be src/main/kotlin

[Vampire]

Btw. your gradleApi and localGroovy dependencies are pretty pointless if you already applied the kotlin-dsl plugin.

[Vampire]

Or rather localGroovy is pointless anyway if you use Kotlin, not Groovy

[rook]

Ok, I was following a blog post about it and I guess I got led astray 😕

[rook]

Well, I changed the directory to be kotlin rather than java and there was no change. I’m getting the same error message

[Vampire]

Actually the kotlin-dsl plugin is more.
It allows you to write pre-compiled script plugins, so you can write the plugins just like you would write the build scripts for the most part, including type-safe accessors for plugins applied with the plugins block.
Very handy for convention plugins.

[Vampire]

Oh, and if you define the plugin definition file yourself, it should be in root/buildSrc/src/main/resources, not root/buildSrc/main/resources like you wrote

[Vampire]

Works fine here with that file in the right place, I copied your info into an empty project and it works

[Vampire]

While I personally would remove that file and instead add to the build script

gradlePlugin {
    plugins {
        register("bluetoothpoc") {
            id = "rook.bluetoothpoc"
            implementationClass = "rook.bluetoothpoc.MyPlugin"
        }
    }
}

[Vampire]

If I want a binary plugin that is.
Or easier a pre-compiled script plugin where the ID is simply derived from package and name

[rook]

Awesome, thanks! I’m trying to create a plugin to help manage module inclusion in build flavors

[rook]

Looks like if I move the resources folder to the directory root/buildSrc/main/resources, it can no longer resolve the id in my plugins block

[rook]

I removed the explicit declaration of the META-INF entry and added the block you recommended and I’m getting the same error as I was originally encountering

[rook]

I mean, ultimately, this is a ClassNotFoundException. But I can’t figure out why it can’t find the class 😕

[rook]

Wait, I’m just now noticing that in the gradle sync logs, it’s not reporting on the build status of buildSrc. Is that normal?

[rook]

That makes me think that buildSrc is not being included in the gradle sync process

[Vampire]

It is

[Vampire]

Well, as I said, I followed your instructions and it worked fine

[Vampire]

You must have some slight notch somewhere

[Vampire]

Where you don't do what you described

[Vampire]

So you need to provide a reproducer otherwise it is impossible to guess your error

[rook]

Ok, I’ll try to reproduce in a fresh project

[rook]

I re-implemented the plugin in a brand new project and I’m having a very similar issue. Here’s the project structure so that you can see where everything is located. @Vampire

Project Structure

[rook]

Here’s where I’m attempting to include the plugin on line 4.

build_gradle_kts___app_.kt

[Vampire]

Easiest would be you simply share that plugin on GitHub or similar, or as a zip if you prefer

[rook]

Here it is

DumpsterFire.zip

[rook]

I figured it out! So, I didn’t realize, but implementationClass has to exactly match package and class name, including letter case 🤦

[rook]

@Vampire Thanks for all the help!

[Vampire]

Yeah, of course it has and in your original description it did

[Vampire]

But good that you solved it

[rook]

I found that there was one more strange piece in the original codebase. Apparently the MyPlugin file did not have an extension. So I guess it wasn’t being identified as a .kt file

[Vampire]

Yes, that was most probably your problem