From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

Where is the code ? :johntravoltalookingaround:

Another issue you might bump into with lambdas is that some of them use invokedynamic starting with some version of Kotlin: <https://github.com/gradle/gradle/issues/17052>
But IIRC, that causes tasks to be not up-to-date, not `NoClassDefFoundError`

I typed it up, but then realized a repro project might be better, so I'm working on that (and naturally I can't repro it) :see_no_evil:

Here's a repro project showing a `NoClassDefFoundError` seemingly caused by a nested lambda that is referenced in bytecode but is not getting compiled to a class file.

If you run:

```cd plugin
./gradlew publishToMavenLocal
cd ../app
./gradlew tasks```
then you should see the failure:

```* What went wrong:
Com_eygraber_publish_gradle$2$1$1
&gt; Com_eygraber_publish_gradle$2$1$1```
To get it to work, edit `plugin/src/main/kotlin/com.eygraber-publish.gradle.kts` line 24 from:

```repositories {
  githubPackagesPublishing(
    owner = "eygraber",
    repo = repoName
  )
}```
to

```repositories.githubPackagesPublishing(
  owner = "eygraber",
  repo = repoName
)```
then run the steps above again and the task will complete successfully.

Whatever issue this is, looks like it happens when compiling the plugin. If you unzip `compiler-issue-plugin-0.0.1.jar` , you will not find a matching .class file for `Com_eygraber_publish_gradle$2$1$1`

What you can do is try to remove the precompiled script plugin support:
```plugins {
    `embedded-kotlin`
    id("org.jetbrains.kotlin.plugin.sam.with.receiver")
    id("java-gradle-plugin")
    alias(libs.plugins.publish)
}

samWithReceiver {
    annotation("org.gradle.api.HasImplicitReceiver")
}

gradlePlugin {
    plugins {
        create("com.eygraber-publish") {
            id = "com.eygraber-publish"
            implementationClass = "MyPlugin"
        }
    }
}```


The `kotlin-dsl` plugin does <https://github.com/gradle/gradle/blob/5d94aa68c0fdbe443838bb977080e3b9f273e889/subprojects/kotlin-dsl-provider-plugins/src/main/kotlin/org/gradle/kotlin/dsl/provider/plugins/precompiled/DefaultPrecompiledScriptPluginsSupport.kt#L117|a bunch of things> to support precompiled script plugins. I'd suspect something is lost there or there is some unfortunate interaction with the Kotlin compiler

By using "regular" (i.e. not precompiled) Kotlin plugins, you'll also save some time. See also <https://github.com/android/nowinandroid/issues/39>

&gt; remove the precompiled script plugin support
&gt; 
I have a feeling that will fix it as well, however I found a workaround that's much less involved (see the end of my previous message)

I'm going to file an issue for it, but I thought I'd put it here first in case anyone was already aware of the problem

&gt; By using "regular" (i.e. not precompiled) Kotlin plugins, you'll also save some time
&gt; 
These plugins are in a different project and are compiled into a separate artifact, precisely to solve the issue you linked :grin:

Share the link to the issue here when you have it so we can :star:

<https://github.com/gradle/gradle/issues/21412>

The question is whether it is a Gradle or Kotlin bug. We'll see.