Main exception: “Selected configuration ‘testApi’ on ‘project :MultiBungee’ but it can’t be used as a project dependency because it isn’t intended for consumption by other components.”
Gradle scan: https://scans.gradle.com/s/62vy4gskmao3q/
// Builds files
MultiBungee: https://pastebin.com/pnQN309Z
MultiCommon: https://pastebin.com/C2SWDpvb
MultiFilter: https://pastebin.com/ZHXCnLN1
Any ideas?
What’s your intention here? There is no such thing as the testApi configuration unless you’re creating it yourself (which isn’t the case in what you’ve shared). The purpose of api vs. implementation is to distinguish between dependencies that contribute to the ABI or not, which impacts the compile vs. runtime classpath, when consumed. Test dependencies aren’t consumed by downstream projects unless you manually wire this up.
It appears to be a thing as the error would be different if it wasn’t. Also how would I go about wiring up transitive test dependencies?
It’s not a Gradle-provided configuration. Gradle introduced the implementation configuration (for all source sets) and the api configuration (only for the main source set when using the java-library plugin), which are consumed by other projects through the apiElements and runtimeElements configurations.
In your build, that configuration is being added by the JetBrains-provided Kotlin plugin. Without combing through the implementation details of that plugin, it’s hard to tell the exact reason they’ve added it, but as it is explicitly configured to be neither consumable nor resolvable, it’s going to be for something internal that they’re wiring up (perhaps correct handling with joint compilation of Java and Kotlin).
You would need a consumable configuration (i.e. testDependencies for example) that has the dependencies that you want to expose to the other project. This could extend the internal testApi configuration that’s being created by the Kotlin plugin for you, if that’s what you want to use.
val testDependencies by configurations.creating {
extendsFrom(configurations.testApi.get())
}
You would then update the consumer to use testDependencies instead of testApi in the project dependency.
From a purist view though, this is often incorrect modeling. The test source set should be tests for the main source set in the project. If the test source set is actually exposing some utilities with API dependencies to the tests of other projects, this likely should be a test utility project with its code in the main source set. If the test source set contains fixtures to help another project write tests against the main code, it’s likely better to separate the fixtures from the tests. If the goal is just alignment of test dependencies between all projects, there’s ways to achieve this without adding artificial dependencies.