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
>>
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
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 "
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:
>
&
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
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
