I couldn't agree more. It really boils down to the simple fact that class loading in the JVM - for the standard classloaders - is well-defined.
If a build tool is not able to reflect this, it is an unreliable build tool. It doesn't matter if anyone thinks CLASSPATH order shouldn't matter from a philosophical point of view. (And inconveniencing deps.edn users to go tell the authors of dependencies to "fix their resources" is not a realistic approach) Providing dependencies in an unsorted map like deps.edn is doing now is inherently unstable. That doesn't necessarily make deps.edn unusable, but - as others have pointed out - a source of surprising errors. Until an order is defined that survives changing OS/JVMs, I will advise anyone to not use deps.edn. Furthermore, all build tools - with the exception of Bazel and derivates - do rely on transitive dependency resolution and thus also are inherently fragile. But either through established practices or defined standards: they offer a way to define an order should conflicts arise. (Take a look at https://issues.apache.org/jira/browse/MNG-1412 again for a longer discussion). At the very least: The location of your own classpath entries must be well-defined. They are by default first on regular CLASSPATH. I wasn't following the latest development on this, but I would assume that is a reasonable demand and has been fixed in newer tools.deps versions? Thanks, Jochen On Sunday, September 13, 2020 at 8:37:31 AM UTC-7 Matching Socks wrote: > Too fragile. This reminds me of the notion of "situated programming", > featured in the talk by Rich Hickey: you and your programs operate in the > middle of a bizarre and changing situation. For Clojure, the Java > ecosystem is part of that situation. Even if some jars do not overlap > today, you will be forced to take a minor update someday that introduces a > clash. Or perhaps (quite likely) jars do overlap today, but you will take > a minor update someday that causes the classpath to emerge from the > hash-map differently and your program won't work anymore. The insight of > the theory of "situated programs" is, not to hit a cliff when a perfectly > legal quirk arises in the situation. > >> -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/e229b29e-304d-4e96-bf26-59b255e3920bn%40googlegroups.com.
