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: 
(search for "first")

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.

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. If that order changes in between minor 
versions of clj, that makes it an unstable build system.
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.

Please return to at least having :paths at the front of the CLASSPATH.


On Tuesday, August 11, 2020 at 2:15:57 PM UTC-7 Alex Miller wrote:

> On Tue, Aug 11, 2020 at 3:01 PM 'bed...@yahoo.com' via Clojure <
> clo...@googlegroups.com> wrote:
>> Here's some maven-specific discussion: 
>> https://stackoverflow.com/questions/793054/maven-classpath-order-issue.
>> They have a defined order since 2.0.9. and declaration order is 
>> considered for transitive dependencies conflict.
> Unfortunately, neither that 11 year old SO answer nor the referenced jiras 
> actually document, explain, or refer to any documentation about the 
> ordering, or afaict commit to anything specific other than reproducibility. 
> I'm not saying this is your fault or anything, just does not seem well 
> defined to me other than as an artifact of implementation.
> For libs, Maven (and I presume lein which relies on Maven libs for this) 
> uses the ordering of deps in the pom wrt the ordering in the classpath. clj 
> intentionally does not include this ordering - the libs are in an unordered 
> map, the version selection algorithm is completely different, etc. If this 
> matters, then one of your deps is broken and should be fixed.
>> Intellij's Dependencies tab in Module settings: You can re-order the 
>> dependencies and they reflect in the classpath.
> Not sure that has anything to do with Maven or lein, seems orthogonal to 
> the question here.
>> lein classpath -> local paths added first, JARs afterwards
>> Please consider returning to a :paths first, then :deps in a stable order.
> I will consider some options.
>> I know it is not pretty and it is not desirable for code to be dependent 
>> on that, but resource-loading uses the CLASSPATH and that makes the order 
>> of dependencies intrinsically linked to locating resources. 
>> I'd also rather fighweel-main behave differently, but it relies on 
>> (io/resource "public/index.html")
> I think that is perfectly ok - the problem here is whether a jar includes 
> that resource, which is likely to conflict. I'd be very interested to know 
> whether this is actually a jar or an issue with the ordering of your local 
> paths. To check where it's finding index.html:
> clj -e "((requiring-resolve 'clojure.java.io/resource) 
> \"public/index.html\")"

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