Apply annotations dependency to testFixturesImplementation

[jamiesanson]

When applying Poko to JVM projects with the java-test-fixtures Gradle Plugin applied, add poko-annotations to testFixturesImplementation.

Closes #393.

[JakeWharton]

I think I would prefer this still be a warning. Kotlin 2.1.0 will allow suppressing specific warnings by name even when using the warnings-as-error setting (see https://youtrack.jetbrains.com/issue/KT-8087).

We'll see what @drewhamilton thinks.

[drewhamilton]

The concern is that a library author adds com.example.MyData to their classpath, but then typos something like pokoAnnotation = "comm/example/MyData" in their configuration, so they have a library full of @MyData annotations but no code generation. This scenario should remain at least a warning, but I'm not convinced it shouldn't be an error.

In #393, Jake said:

It might be better to no-op the compiler plugin if the runtime isn't present in a compilation unit.

Why is this better?

[JakeWharton]

The motivating example was the compiler plugin being applied to all Kotlin compilations in the Gradle project (including test fixtures, specifically) but the annotation not being present in the associated configurations.

[drewhamilton]

Yes, sorry, I meant why is this approach better than either (a) not applying Poko to test fixtures configurations by default, or (b) adding the annotations dep to test fixtures configurations by default?

My gut says (a) makes more sense, because maintaining binary compatibility in test fixtures is rarely if ever needed, but maybe that's wrong?

[JakeWharton]

I don't believe we get a choice in the fact that the compiler plugin is applied. Test fixtures support compiling Kotlin and I would expect any plugins to go along with that automatically (with our use of the subplugin plugin thing).

We can add the first-party dep automatically by special-casing the test fixture plugin. That was proposed. The only case you'd need to manually intervene then is if you did a compileOnly of your own dep with an annotation.

[jamiesanson]

Yeah, this PR isn't ideal - hadn't properly considered that typo case, agree this should be at minimum a warning.

---

My original suggestion was to special case it, and add the annotations dependency automatically. Test fixtures end up being published artifacts of a library, so figured that while maintaining binary compatibility probably isn't needed all the time, some library authors may strive for it. Having Poko automatically apply this dependency to testFixture compilations as it does to other ones feels preferable here.

Manual intervention would be pretty obviously needed if a developer typos, or adds their own annotation dependency to the wrong configuration - this error would persist, and could be made a little more descriptive to point them in the right direction.

[drewhamilton]

I don't believe we get a choice in the fact that the compiler plugin is applied. Test fixtures support compiling Kotlin and I would expect any plugins to go along with that automatically (with our use of the subplugin plugin thing).

KotlinCompilerPluginSupportPlugin has an isApplicable function that we set to true but could be more selective based on the input KotlinCompilation. So I think we could skip applying it to test fixtures if we wanted to.

But if test fixtures are generally published with the library, it seems like special-casing the inclusion of the annotation dep for test fixtures, as @jamiesanson initially proposed, is the most intuitive behavior.

[jamiesanson]

Apologies for taking a while to get back around to this - pushed a few commits to revert the ERROR -> INFO change and apply the annotation dependency to test fixtures automatically. I've also added `java-test-fixtures` to the JVM sample, which acts as a test case - ./gradlew build fails without the change to add the annotation dependency.

[JakeWharton]

This is probably fine to start with. We may have to move this outside the if at some point as support is expanded.

[drewhamilton]

Sorry for the delay – looks great, and thanks for adding to the sample too.