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

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

Start with the nebula.facets configuration and the Apache Geode integrationTest classpath example shown in the issue. Determine whether the ordering is inherent to the facet and whether configuration can place the main source-set output immediately after the test facet. Done means an established cause and a documented or implemented way to achieve the requested ordering.