This message was deleted.
# community-support
s
This message was deleted.
v
Test fixtures are not only meant for usage within one build, but also to provide test fixtures or test utilities for downstream projects, which is why they are published by default. I think if there are really circular dependencies that cannot be resolved when using the library that might be an error. Maybe you can knit an MCVE that demonstrates this problem. To not publish the test fixtures, Thomas already gave the appropriate link.
m
In this case, the main use of test fixtures was that it was cleaner to put the test sources and test fixture sources in separate source sets; the test fixtures were only used locally within the same module. All my test fixture classes currently have package-private visibility, and some of them reference package-private classes in the main source set. (Wouldn't rule out public test fixtures classes consumed by multiple modules in the future, but the test fixtures will still be for internal testing purposes, not for publishing.) Thomas's link worked for me; the one minor inconvenience is that since only some published module uses
java-test-fixtures
, I have to repeat that same snippet for each module that needs it, as adding it once in
buildSrc
. My publishing conventions plugin only uses the
java
plugin, and that's only for enabling sources and Javadoc JARs (as well as setting
-Werror
for Javadoc).
v
Copy code
pluginManager.withPlugin("java-test-fixtures") {
    // disable publishing of test fixtures
}
?
๐Ÿ‘ 2
p
Yes, at sqldelight we also use test fixtures and publish them for dialect authors, but we get feedback from users regarding circular dependency warnings when consuming the normal dependency without impact on the build thought. And itโ€™s really strange given we use Gradle and the users too, so gradle should not warn the users.
v
You should maybe report an issue then. Doesn't sound like this should happen.