Yeah, indeed happens only in the tests 😕

Interestingly, that issues says it worked with 8.0.2, but I have the problem on 7.6.3

An there the work-around with system property also does not work 😭

Ah, too bad, that system property was introduced only with Gradle 8.1 and I'm currently pinned to 7.6.3

Do you have an idea why it should make a difference to use use

withPluginClasspath

vs. using a deployed version from a repository? I'd like to understand what the difference is to maybe see another work-around before changing the infrastructure completely.

I guess I just make those functions

internal

for now. It would be nice to have them downstream, but it's not particularly necessary.

They are just the ones from https://github.com/gradle/gradle/issues/25550, so worst I just copy the file if I need them downstream too

Hm, interesting ... strange but interesting. The difference between testkit and actual usage - or usage with local repo - is maybe actually jar vs. directory with classes. If I filter the

pluginClasspath

on the

GradleRunner

to remove the classes output directories and instead put in the jar file with the code, the testee build script cannot find the classes. If I filter the

pluginClasspath

to just remove the classes output directories and add the jar file with the code using

buildscript { dependencies { classpath(files("$codeJar")) } }

the test works fine with the public inline functions. So while the public inline functions seem to only be a problem in individual class files but not within a jar, putting the jar onto the

pluginClasspath

seems to not work. 👀

Hm, no, I even have to add it to

pluginClasspath

and via

buildscript

block. This is really strange.

Is the inline function actually used from your build-logic?

If it's not, maybe something can avoid checking that part in some cases

Although I would expect the other way around TBH like .jar checking everything when .class could be more granular 🤷

Whether the inline function is used should be irrelevant. But in the test I'm looking at right now it is not.

Hm, no. I tried copying together

build/classes/kotlin/main

and

build/resources/main

to

build/combined

and used that, in the

pluginClasspath

but it still failed with the problem. Then I just did

jar --create --file combined.jar -C combined .

and tried with

combined.jar

instead of

build/combined

et voila, the test succeeds. 😕

I start to doubt my senses. With that

combined.jar

the test is green. If I place in the same spot the Gradle-built jar, which according to IntelliJ diff is identical except for the

Created-By

manifest entry, it fails with not finding a package in it.

Am I that tired?

wtfh?!? If I just copy the Gradle built jar to a different spot and use it from there it does work.

Do you have a reproducer around? I can try see what it does on my machine

Hm, I thought this might be some f***ed up state, but at least deleting

build/tmp/functionalTest/work/.gradle-test-kit/

did not change anything

There can nowhere else be state hanging, can there?

I'm really confused right now

.withDebug(true)

=> fails with package in import not found

.withDebug(false)

=> works

But still strange that also only when using that jar in that location

This must be a really abstruse edge-case probably

Ok, so eradicating that problem by not using debug mode, the initial problem indeed turns out to be jar vs individual classes. So just putting the jar instead of the classes dirs on the plugin classpath resolves the original issue. While the question is whether not instead also using a jar should fail like that. 😕

Oh boy. If you • either ◦ have

implementation(project())

◦ and putting the actual code jar in its default location to the

pluginClasspath

• or ◦ have the classes directories on the test dependencies like with the default

test

task ◦ and having the classes direcotries in the

pluginClasspath

• and

withDebug(true)

• and applying

jacoco

plugin then it fails to find the classes as the code is filtered out from the compile classpath before compiling the script in this line: https://github.com/gradle/gradle/blob/master/platforms/core-configuration/kotlin-d[…]org/gradle/kotlin/dsl/provider/KotlinScriptClassPathProvider.kt

Thanks for your help investigating these issues @Martin

That doesn't give a fix though, right? You'll either have to disable something or wait for a fix?

It at least allows to properly work-around. I'm polishing the reproducer for a new issue, then you can have a look. It has 5 variants, 2 of which are failing. You just have to use one of the other 3, making sure the

pluginClasspath

has the classes in a different place than the "gradleImplementationClassPath", so that they are not filtered out.

The problem more was to find it out. Especially as for simplicity I first moved things from a separate test suite to the default "test" test suite and suddenly it started failing there where it worked fine in the actual project, because the "test" test suite depends on the classes dirs while the "functionalTest" test suite depends on the jar.

Don't try to understand this, I gnarled 3 days over this to understand what the hell is going on. 😄

And with 2 out of those 3 you also work-around the problem with the public inline functions, while I still think they should actually fail also and the actual issue is, that those are not failing. 😄

Here the issue with reproducer if you are curious: https://github.com/gradle/gradle/issues/27860 🙂

Oh, and one further work-around is to re-add the stripped out dependency by using

buildscript {
    dependencies {
        classpath(files("$codeJar"))
    }
}

in the testee, forgot to mention that in the issue. 🙂