Change PluginClasspath for tests to binary plugin from maven local

[rougsig]

Background
Plugin can't works in test with classes that were loaded by gradle project.

For example:
Our plugin works with classes from agp. Agp is not bundled into plugin.
Plugin checks is agp was applied, but for some reasons ClassNotFoundException will be thrown. BaseExtension not found.

withPlugin("android") {
  // if we are here it means gradle has successfully loaded agp plugin
  project.android as BaseExtension
}

Changes
Remove withPluginClasspath from tests. Provide the plugin under test via maven local. Before the test run, gradle will publish the plugin to maven local.

Test plan
Green pipelines.

Source of the problem
withPluginClasspath loads the plugin under test to classloader_1. Gradle loads applied plugins to classpath_2. classpath_1 is the parent to classpath_2. The parent classpath cannot work with classes loaded by child classpaths.

References
gradle/gradle#11338
https://discuss.gradle.org/t/testkit-somehow-excludes-compileonly-dependencies/19842/5

[ejona86]

We'll probably want to do a release before we do this. In particular, upgrading gradle-plugin-publish changes semantics in ways you have to carefully read the release notes to catch.

But I also think we should just do a release now-ish. I think #612 is the main thing that'd cause us delay. But even that, I'd be okay with a patch release.

[rougsig]

Yes of course.

I tried to run android functional tests. But this issue blocks me gradle/gradle#11338 (comment), https://discuss.gradle.org/t/testkit-somehow-excludes-compileonly-dependencies/19842/5, trying for workaround.

TLTR: for some reasons gradle test runner doesn't include compileOnly to test classpath.

I created a draft to run tests, my current PC doesn't have enough RAM to run android tests.

[ejona86]

for some reasons gradle test runner doesn't include compileOnly to test classpath.

Wouldn't that need to be testCompileOnly? And I'd never expect the test runner to use it, as that is runtime; I'd only expect javac to use it.

I created a draft to run tests, my current PC doesn't have enough RAM to run android tests.

I figured it was something like that. It runs a lot faster in the CI with running each test in parallel. I had just noticed you were working on it and gave a peek.

[ejona86]

I created a draft to run tests, my current PC doesn't have enough RAM to run android tests.

FWIW, you can also create PRs on your own personal fork, and I think Github Actions will still work there without any real issues (although I can't say I've actually done it for protobuf-gradle-plugin since we swapped to github actions). (I used to do that all the time for Travis-CI while I was debugging Travis-specific problems and trying new config.)

[rougsig]

But I also think we should just do a release now-ish. I think #612 is the main thing that'd cause us delay. But even that, I'd be okay with a patch release.

I think we can create patch release after #612. Also we need to remove/replace idea plugin, via to gradle/gradle#22233.

About release. I think we can merge #616 and do a release.