On Tue, Aug 11, 2020 at 6:41 PM 'bed...@yahoo.com' via Clojure < clojure@googlegroups.com> wrote:
> Just 2 quick points before I go back to migrate to shadow-cljs & leiningen > ;) > > "just does not seem well defined " > This is not a line of argument you want to pursue when we are talking > about maven, who has had a stable order for what feels like decades now. > If you need a current link: > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies > (search for "first") > I understand it may feel like that to you, but I have been using Maven for at least 15 years and have spent a lot of time fighting classpath ordering issues while using it. That link says nothing about classpath order and I spent some more time today looking for something like that, without success. There are plenty of Maven tickets about this, it's changed over the years, and a lot of complexity to cover when you start to consider parent poms, dependency management, etc. I don't think it's as fixed as you think it is, probably more that they just don't touch it much (and most differences don't actually matter). It may be stable largely by fear. > To your comment re Intellij: you can actually use Intellij to build and it > uses its own project configuration to do that and cobble together the > classpath (in many cases it merely syncs with maven/lein etc.). In a way, > Intellij acts like clj: It builds a classpath and runs stuff. > Yeah, I use it every day. My point was just that it's independent from what we're talking about. > Also, arguing that "JARs need to be fixed" is interesting, as I can get > *any* resource with `(io/resource...)` and will get different answers > depending on CLASSPATH order. > You can only get different answers if two roots have the same resource, which again, is bad, and the cause of a big percentage of dependency issues I've tracked down at one point or another. Same resource = shadowing = eventually you will reorder your deps and see something different. > If that order changes in between minor versions of clj, that makes it an > unstable build system. > I'd say if that's coming from dependencies, then it's your build deps that are unstable, you just didn't know it. The ordering of project paths before deps is a separate issue. > Just try to io-resource '/log4j.properties', for funsies. If in version A > of clj I'm getting my own /log4j.properties and in version I'm getting the > one from some other JAR, it's a problem. > > If I run > find . -name "*.jar" -exec unzip -l {} \; | awk '{print $4}' | sort | less > in ~/.m2 > to crudely get all file names for all my cached jars, > I can find 4 instances of 'public/index.html' > 3 of 'public/css/style.css' etc. etc. > You are proving my point. That's all broken. Those libs cannot control where they are placed in an application's classpath and whether they will shadow or be shadowed by something else. They are time bombs waiting to break your build. You should complain to their creators. > Please return to at least having :paths at the front of the CLASSPATH. > As I said, that's a different issue and I'm inclined to agree with you. The details of changing it are more complicated than it appears. -- 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/CAOdgdgx37zdsApu6zAqBFMZ-yPzGSt_OmE%3DOaW%3DywFfB3YinEQ%40mail.gmail.com.
