Ok, let's reset as we start talking about different things now.

None of these libraries are broken. They just include resources. Also, I 
don't think it is realistic to tell library authors to please move certain 
files out of the way because my build tool randomizes my classpath. That is 
not going to happen. People will keep including things like 
log4j.properties that are in potential conflict with a local file or files 
in other JAR paths.

The question remains: Should my build tool allow me control over the order 
of the classpath? I believe the answer is yes. 
(Even gradle gives you that control and/or offers ways to ensure that my 
chosen paths and libraries are first on the classpath.
Regarding maven: Even if there would be no documentation at all, their 
algorithm has not changed since 2.0.9. It's the Normative Kraft des 
Faktischen at play. )

If the build tool from version A to version B changes this order, it is not 
a usable tool. I can't make this point any clearer.
We might agree to disagree here, but a build tool should not be at liberty 
to sort top-level dependencies at will.

Note that this is completely independent from the thought that order 
*shouldn't* matter.
When in fact it does matter. It is an unfortunate reality. That's simply 
how resource loading works in Java.

I understand that building dependency trees is not trivial, but it is 
rather trivial to ensure :paths comes before everything else.
Please define some stable order and establish a top-level order for 
explicit dependencies. That makes builds deterministic.

Thanks for looking in this issue,

PS: happy to learn you got in touch with the homebrew team. That is 
excellent news.

On Tuesday, August 11, 2020 at 6:01:18 PM UTC-7 Alex Miller wrote:

> On Tue, Aug 11, 2020 at 6:41 PM 'bed...@yahoo.com' via Clojure <
> clo...@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