Hi, this is a very gradle question so if it can’t ...

# gradle

[Justin Tullgren]

Hi, this is a very gradle question so if it can’t be answered no worries..

Does anyone know how to use gradle’s testkit withPluginClasspath method to include the gradle plugin under test while also having a test set up that uses a plugin in the gradle plugin portal?

We have a set of gradle plugins that set conventions on other plugins, for example the kotlin jvm plugin. To test them we build up a test build.gradle.kts file with our plugin under test id AND a real kotlin plugin. However if we use withPluginClasspath then testkit can’t find the kotlin plugin.

[trevjones]

i basically always have my test task depend on publish to maven local and just let the test project load it from that. always seem to go the best for me that way

[Justin Tullgren]

ya we did that. we just have a use case now that makes it hard to do that successfully. Thank you for the thought though

[mbonnin]

Same, I avoid withPluginClasspath at all cost.
@tony also has a small little plugin to help with this: https://github.com/autonomousapps/dependency-analysis-gradle-plugin/tree/main/testkit

[Justin Tullgren]

dope thanks! i’ll check it out.

I have been running into many problems with the withPluginClasspath so I am glad to know I am not the only one

[tony]

I also wrote a blog post which explains at length why I don't use that method https://dev.to/autonomousapps/defensive-development-gradle-plugin-development-for-busy-engineers-486c

[hfhbd]

I generally include my developed plugin as a includedBuild in the test build and use all other external plugins as usual.

[Vampire]

If publishing to test, better publish to some dedicated separate local repository rather than mavenLocal or otherwise make sure to use a repository content filter. mavenLocal is broken by design in Maven already, and makes builds slow, and if used lightly flaky at best broken silently at worst.

But besides that, what does "However if we use withPluginClasspath then testkit can’t find the kotlin plugin." mean in error messages? withPluginClasspath iirc adds your plugin's runtime classpath to a parent class loader, similar to dependencies in buildSrc. If your plugin then wants to use some plugin classes that are added by the target build those are on a descendent class loader and cannot be found, so you would need to add it to the injected classpath if not using local publishing for testing.

[Justin Tullgren]

That’s a good point i’ll check that out.

For more context on the error.

We will generate a build.gradle.kts file like so (off the top of my head, not exact syntax but close enough i hope to give you the idea)

plugins {
  id("org.jetbrains.kotlin.jvm") version "x.x.x"
  id("plugin.under.test")
}

and we will generate a settings.gradle.kts file like so

pluginManagement {
  repositories {
    mavenCentral()
    gradlePluginPortal()
  }
}

dependencyResolutionManagement {
  repositories {
    mavenCentral()
  }
}

and when test kit runs the gradle build we get the error

no plugin found with the id [“org.jetbrains.kotlin.jvm”].

There is also a bunch of meta space(?) errors with the build cache. I don’t believe this to be the issue cause i delete the cache all the time and it still fails.

[Vampire]

Hm, that opposes a bit what I assumed and also explained in https://discuss.gradle.org/t/testkit-load-plugins-other-than-plugin-under-test/51534.
I'd say the external plugin should be found just fine, no plugin found with the id ["org.jetbrains.kotlin.jvm"]. seems strange.
If your plugin would not find the classes if it only has a compileOnly dependency, that would have been my guess without that information.

What is the full error message?
If it says it did not find the plugin with that id, it should also tell where it looked for it.

[Justin Tullgren]

one minute and i’ll get you the error. thank you

[Justin Tullgren]

Untitled

Untitled

[Vampire]

o_O
Never seen something like that as far as I remember.

[Justin Tullgren]

ya i was having a hard time finding anything either sad panda and the only related meta issues were logged as bugs and the answer was delete the cache

[Justin Tullgren]

i have workaround which is not ideal but I am not blocked if you don’t have any other ideas. I do appreciate your answers though.

[Vampire]

Sounds related to https://github.com/gradle/gradle/issues/28974 just that there it happens with production builds not TestKit and TestKit should start with a fresh directory I think so deleting caches does not sound helpful. 😕

[Vampire]

You should probably add to that issue or report a separate one. 🤷‍♂️

[Justin Tullgren]

okay i will. thanks for your time!

[tony]

If publishing to test, better publish to some dedicated separate local repository rather than mavenLocal or otherwise make sure to use a repository content filter.

my testkit-support plugin publishes to a separate repo in the build/ dir fyi