Changing the order of classpath entry and not having paths be at the
beginning of the CLASSPATH will break existing code that uses `(io/resource
...)` to load resources from the CLASSPATH.
While in theory the order of the classpath should not matter, in practice
it does, often involuntarily.
Fig
iller wrote:
> Just to beat the horse...
>
> On Tue, Aug 11, 2020 at 1:05 PM 'bed...@yahoo.com' via Clojure <
> clo...@googlegroups.com> wrote:
>
>> Changing the order of classpath entry and not having paths be at the
>> beginning of the CLASSPATH will
etc. etc.
Please return to at least having :paths at the front of the CLASSPATH.
Thanks,
Jochen
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:
>
&
te:
> 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 "
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
etc), then alpha per depth so this should greatly improve
> reproducibility of lib ordering across builds.
>
>
>
>
> On Monday, September 14, 2020 at 7:51:07 AM UTC-5 Alex Miller wrote:
>
>> Just FYI, we have a plan to address this and it should be in the next
>>
