I believe it is generally true that the Clojure-maven-plugin has
non-deterministic ordering of namespaces it auto "discovers" for its various
goals that involve namespace discovery.
This has been a source of frustration for me in the past as far as trying to
get determinism with test behaviors
I could be wrong, but I think I've seen this before under these
circumstances:
Clojure namespace ns-a imports Java class SomeClass.
Clojure namespace ns-b requires ns-a.
Clojure namespace ns-b refers to SomeClass, and everything works smoothly.
Then ns-a stops importing Java class SomeClass, and
I've seen non-determinism across machines with regard to multiple
namespaces being searched to AOT with the clojure-maven plugin (only
noticed because it resulted in an error). The workaround was to specify a
single entry point namespace to clojure-maven and let the clojure compiler
sort out namesp
Clojure 1.8 both before and after; I should have put that in my original
post. As far as I'm aware there were no changes of any kind in the
environment or code between the failing state and the successful one,
although since I don't control our CI environment it is possible there were
environm
Most helpful would be to know what Clojure version you are on now and what
changed between when it didn't fail and when it did.
There have been a variety of changes to both type hints and classloading
over the last few releases and it's likely that the error is now simply
found when it was sile
I have a case where JVM Clojure code like (some-> ^JavaClassA this
^FieldTypeA (.getFieldTypeA) (.getFieldTypeB)) previously compiled for a
long time and suddenly just started failing in our CI system because the
class FieldTypeA wasn’t imported in the namespace. I understand the need
to impor
