I'll have to check what the plugin was that enabled Groovy DSL precompiled script plugins, but my recommendation is to use Kotlin DSL everywhere. By now Kotlin DSL is the default, you immediately get type-safe build scripts, actually helpful errors if you mess up the syntax, and amazingly better IDE support if you use a good IDE like IntelliJ IDEA or Android Studio. 🙂

groovy-gradle-plugin

is the plugin you need for Groovy DSL precompiled script plugins

converted to kotlin, but still receive:

Task :jar

🫙 A valid plugin descriptor was found for com.my-config.properties but the implementation class my-config.gradle.kts.MyConfigPlugin was not found in the jar.

the plugin gradle file is located in buildSrc/main/kotlin/my-config.gradle.kts

./build.gradle.kts:

plugins {
    kotlin("jvm") version "2.1.10"
    id("java-gradle-plugin")
    id("maven-publish")

    id("com.jfrog.artifactory") version "5.+"
}

group = "com.mycompany.myproduct"
version = "1.0-SNAPSHOT"

repositories {
    mavenCentral()
}

dependencies {
    testImplementation(platform("org.junit:junit-bom:5.+"))
    testImplementation("org.junit.jupiter:junit-jupiter")
}

tasks.test {
    useJUnitPlatform()
}

./buildSrc/src/main/kotlin/my-config.gradle.kts:

plugins {
    id("checkstyle")
    id("java-gradle-plugin")
    id("jacoco")
    id("maven-publish")
    id("pmd")
}

group = "com.mycompany.myproduct"
description = "Gradle Plugin containing Common myproduct Configuration settings"
version = "1.0.0"

repositories {
    maven { url = uri("<https://mycompany.repository/java>") }
    mavenLocal()
}

dependencies {
    testImplementation platform("org.junit:junit-bom:5.+")
    testImplementation "org.junit.jupiter:junit-jupiter"
}

Besides that using

mavenLocal()

is a very bad idea. At least it is the last one, but it should practically never be used and if, then only with a repository content filter. 🙂

But that is not related to your problem

attached is the generic project - thanks

And regarding your MCVE, you configure your main build to produce a Gradle plugin, but the code is in the

buildSrc

build.

buildSrc

is a complete own build that "happens to run" before your main build and the result added to the buildscript classpath of your main build. You must not mix up those two builds. If you want to customize the

buildSrc

build, you have to do it in the build scripts of that build, not in your main build. So if you just remove the

id("java-gradle-plugin")

and the whole

gradlePlugin { ... }

block from your main build script, and instead add a build script to your

buildSrc

build where you apply the

kotlin-dsl

plugin and define a repository, it will work better. Better in this case means that

buildSrc

will fail to compile, as your plugin is not proper Kotlin syntax.

Besides, that you should change the file name to have a dot in the plugin id

The kotlin 'commonconfigplugin' class has code in it that relies on org.gradle.api classes - how do those get imported? id("java-gradle-plugin") does not work

As you still apply the plugin dev plugin on the main build, what actually do you try to do?

do you try to develop plugins in the main build there that are then used by other projects in the company?

Or do you try to use

buildSrc

in one build to configure all the projects in that one build uniformly?

I guess the former, but then having the class in the

buildSrc

build is not what you want, because what you have in

buildSrc

is for usage in the main build of exactly that build you are running, not to develop something you publish and other builds are using.

(btw, thanks for your patience)

i thought adding the implementationClass = CommonConfigPlugin applied the tasks for checkstyle/pmd

i thought adding the implementationClass = CommonConfigPlugin

That does only tell the plugin dev plugin what implementation class to use for the given id

In the consuming project you would then apply the plugin by id which causes the plugin's

apply

method to be executed

ok, so I need an apply method within my plugin?

well, yes, that is where you do the work

It seems you have really no idea at all what you are doing 🙂

Really, not trying to be mean

and that lives right in the plugin's build.gradle.kts

?

It has nothing to do with what your plugin does when it is applied somewhere

there really isn't much in the plugin documentation regarding this

Then you probably didn't look at the correct pages