This message was deleted.

try using testApi instead of testImplementation to add a dependency on the library - then it should be visible to the consuming project

Could not find method testApi() for arguments

have "id java-library" in that build.gradle also. Is testApi from a version later than 6.0.1?

ah, does the plugin apply the ‘plain’ Java plugin? Try using the Java Library plugin instead

Thank you for responding, but still no joy:

plugins {
        id 'java-library'
}
apply plugin: 'java-library'

The above is from the file with testApi failure.

hmm, I’m misremembering something then. I just tried it locally and yes, testApi is not available with Java Library.

I have attempted api, implementation, testImplementation and testRuntimeOnly against that library. Only testCompile works. Something must be different in how various classpaths are populated and/or shared.

the docs go into more detail about ‘implementation’ vs ‘api’ , and why they replace ‘compile’, but the short answer is that ‘compile’ is too leaky and overshares dependencies, even when they’re best not shared. ‘implementation’ is generally better because it’s more defensive, but sharing dependencies by defining them as ‘api’ can be useful sometimes (as you’re finding out!)

regular api vs implementation differences I understand. Its this corner case with a static initializer / test library that is giving me grief.

it is possible because I have testApi in some projects, I’m just trying to figure out what plugin is defining it…

thank you.

I think it’s coming from the Kotlin JVM plugin, which you probably don’t want to add just to get testApi

I was avoiding java-test-fixtures. Will try now.

I really recommend test fixtures, they’re a really neat way to share test utilities and keep the test sources clean. But in this case, you don’t need to dig into all of that. The plugin can be used just to provide the necessary Gradle config

This is a really old project. But times require we upgrade / update.

1. apply

java-test-fixtures

in the providing subproject 2. expose the library using

testFixturesApi(...)

3. in the consuming subproject, add a dependency using

testImplementation(testFixtures(project(":my-library")))

... running ...

possibly more dependencies need to be exposed

--info suggests still same problem. Not saying that means you are wrong. Just my source of clues.

Gradle has a util for auto converting a Maven project to a Gradle project, and it will convert all dependencies to be ‘api’ dependencies, because even if it’s not best practice it’s closer to how Maven dependencies work, so it will at least convert the Maven config to a Gradle project that works. I mention this because it’s similar to migrating from ‘compile’ to ‘api’/‘implementation’

Adam. Thank you again. I have to step away for a little bit while there is still light outside. Will keep experimenting.

my pleasure, enjoy the fresh air

Actually, you can find

testApi

in the Gradle userguide (while it indeed does not exist 😄)

@adam @Vampire Follow up: testFixtureApi did allow me to repair the dependency problem. Still took an extra day to isolate the areas impacted. Like I said, 156 subprojects.