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
For more options, visit this group at
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 

Reply via email to