Back to classpath discussions again: I talked with Alex Miller about classpath stability and tools.deps.alpha and he confirmed that there is a very specific ordering used for the classpath that t.d.a produces and that it is reproducible across machines. The classpath produced by poly when running tests is not reproducible across machines -- although my fork (mentioned above) fixes one aspect of that, namely ensuring the paths (src/test/resources) do at least come first, before the JAR and local dependencies. I have also confirmed that this lack of reproducible classpath order was the cause of the "incompatible class exception" I ran into (above) that persisted even with the external test runner -- because it's a classpath problem and the classpath poly test produces depends on the hashes of those paths -- so having a different path to .m2 produces a different ordering, so poly test is not deterministic across machines. I'm going to dig into how poly test builds the classpath, with a view to trying to leverage t.d.a more directly than it does today -- which I had advised very early on in the switch from lein to deps.edn (remember our discussions about that @tengstrand?) -- to try to get the classpath built by poly test to at least be consistent across machines and, hopefully, get it to match what t.d.a. would produce, given the same set of deps.edn files (tricky, since poly test has to use a projection of the :test alias across all the bricks to pick up test-specific paths and deps). This work will be independent of the external test runner work -- which I plan to clean up and get into a suitable state for a PR soon.

I've created https://github.com/polyfy/polylith/issues/260 and https://github.com/polyfy/polylith/issues/261 to act as discussion points for both of these issues, and I plan to work on PRs for both. Feedback welcome.