Facet is transitively including its own project output on the classpath before the class files

[rhoughton-pivot]

Our test facets are putting the project's main source-set output at the end of the classpath, and we get the jar via a transitive dependency between modules (geode-core:integrationTest -> geode-dunit:main -> geode-core:main)

Is this an artifact of using nebula.facets? How can we configure the facet to put the main source-set first, or at least right-after the test-facet itself, instead of at the very end?

When inspecting the classpath of a test in Apache Geode (a multi-module project), I have found that the classpath looks like:

/Users/rhoughton/workspace/geode/geode-core/build/classes/java/integrationTest
/Users/rhoughton/workspace/geode/geode-core/build/resources/integrationTest
/Users/rhoughton/workspace/geode/geode-dunit/build/libs/geode-dunit-1.15.0-build.0.jar
/Users/rhoughton/workspace/geode/geode-gfsh/build/libs/geode-gfsh-1.15.0-build.0.jar
/Users/rhoughton/workspace/geode/geode-log4j/build/libs/geode-log4j-1.15.0-build.0.jar
/Users/rhoughton/workspace/geode/geode-deployment/geode-deployment-legacy/build/libs/geode-deployment-legacy-1.15.0-build.0.jar
/Users/rhoughton/workspace/geode/geode-cq/build/libs/geode-cq-1.15.0-build.0.jar
/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/lib/tools.jar
/Users/rhoughton/workspace/geode/geode-core/build/libs/geode-core-1.15.0-build.0.jar
/Users/rhoughton/workspace/geode/geode-membership/build/libs/geode-membership-1.15.0-build.0.jar
/Users/rhoughton/workspace/geode/geode-tcp-server/build/libs/geode-tcp-server-1.15.0-build.0.jar
/Users/rhoughton/workspace/geode/geode-http-service/build/libs/geode-http-service-1.15.0-build.0.jar
/Users/rhoughton/workspace/geode/geode-logging/build/libs/geode-logging-1.15.0-build.0.jar
/Users/rhoughton/workspace/geode/geode-management/build/libs/geode-management-1.15.0-build.0.jar
/Users/rhoughton/workspace/geode/geode-serialization/build/libs/geode-serialization-1.15.0-build.0.jar
/Users/rhoughton/workspace/geode/geode-common/build/libs/geode-common-1.15.0-build.0.jar
/Users/rhoughton/workspace/geode/geode-unsafe/build/libs/geode-unsafe-1.15.0-build.0.jar
/Users/rhoughton/workspace/geode/geode-junit/build/libs/geode-junit-1.15.0-build.0.jar
/Users/rhoughton/workspace/geode/geode-concurrency-test/build/libs/geode-concurrency-test-1.15.0-build.0.jar
<LOTS of 3rd party jars from .gradle/caches>
...
/Users/rhoughton/workspace/geode/geode-core/build/classes/java/main
/Users/rhoughton/workspace/geode/geode-core/build/resources/main
/Users/rhoughton/workspace/geode/geode-core/build/generated-resources/main

[chali]

hey @rhoughton-pivot this would be done by facet plugin but it is mimicking standard Gradle behavior. test will also get main on test classpaths. I assume you are getting some sort of class conflict. I would expect only those folders bringing core classes:

/Users/rhoughton/workspace/geode/geode-core/build/classes/java/main
/Users/rhoughton/workspace/geode/geode-core/build/resources/main
/Users/rhoughton/workspace/geode/geode-core/build/generated-resources/main

If there is another source of a different version I would investigate how that is getting to your classpath.

[rhoughton-pivot]

Sorry, I didn't bold the pertinent lines, because they were in a code block.

geode-core integrationTest facet depends on project(geode-gfsh) (main, which it gets as a jar), which in turn depends on project(geode-core) (main, which it gets as a jar). So now, geode-core integration test has its main classes on the classpath as both its jar (transitively) and its build/classes/java/main.

My curiosity is, is there a way to either detect that cycle and not do it, or to ensure that the build/classes/java/main is in front of the transitive dependency on its own jar ?