This is excellent news! Thank you very much!
On Monday, September 21, 2020 at 7:39:25 PM UTC-7 Alex Miller wrote:
> These changes are in the new 1.10.1.693 prerelease of clj if you want to
> test it. Assuming things look good, I'll promote that to a stable release
> soon.
>
> In this release,
These changes are in the new 1.10.1.693 prerelease of clj if you want to
test it. Assuming things look good, I'll promote that to a stable release
soon.
In this release, things will be ordered :extra-paths (in order, if used),
then :paths (in order, if used), then libs. That reverts the changes
Just FYI, we have a plan to address this and it should be in the next stable
version.
> On Sep 14, 2020, at 1:00 AM, 'bed...@yahoo.com' via Clojure
> wrote:
>
>
> I couldn't agree more.
>
> It really boils down to the simple fact that class loading in the JVM - for
> the standard classload
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
Too fragile. This reminds me of the notion of "situated programming",
featured in the talk by Rich Hickey: you and your programs operate in the
middle of a bizarre and changing situation. For Clojure, the Java
ecosystem is part of that situation. Even if some jars do not overlap
today, you
Alan,
> 4. I could possibly try to replicate your proposed experiment explicitly,
but I no longer have easy access to 1.10.1.645 since Homebrew has been
fixed. I did find the `brew-install` repo on GH, but am not certain how to
replicate the broken install of *.645.
Per the clojure/homebrew-tool
Hi Alex,
1. Great news that the Homebrew team has responded to your request to point
only to stable versions.
2. The resources directory is the contains the path
`resources/public/index.html`. The local one is definitely not the one
being served in my original example (2nd half) re 1.10.1.645 wh
I'd like to point out that tools.deps.alpha can build a differently-ordered
classpath from the exact same input files when run on a different machine
(i.e., the same source/deps, the same version of t.d.a./CLI).
This has bitten me a couple of times with depstar which I use for building
JARs/uberja
>
> 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
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 goi
FYI, I've been working with the homebrew team today and homebrew-core now
points to the latest stable clojure tools version and will track that
automatically going forward.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send
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
Can you change that resources file and see if what you're looking at
changes to double check? I did actually check a bunch of jars from the
prior message and did some searching for that message. Or you could even
dump the classpath with -Spath, then move resources to the front, then use
-Scp (which
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://mav
Hi - I just tried your suggestion and no joy:
~/work/tmp810/xanadu > clj -e "((requiring-resolve '
clojure.java.io/resource) \"public/index.html\")"
DEPRECATED: Libs must be qualified, change deps-ancient =>
deps-ancient/deps-ancient (deps.edn)
DEPRECATED: Libs must be qualified, change reagent
On Tue, Aug 11, 2020 at 3:01 PM 'bed...@yahoo.com' via Clojure <
clojure@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 tr
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.
Intellij's Dependencies tab in Module settings: You can re-order the
de
Just to beat the horse...
On Tue, Aug 11, 2020 at 1:05 PM 'bed...@yahoo.com' via Clojure <
clojure@googlegroups.com> wrote:
> 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 resource
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
This might be a good incentive for people to keep their published .jar
files clean. Unfortunately many published CLJS libs contain the rather
common "public" folder with "public/index.html" and often compiled .js
artifacts which aren't actually ever used.
I do however think that it is useful to
Bunch of things here...
Clojure maintains its own brew tap and a "stable" release that you can
obtain with `brew install clojure/tools/clojure` (the brew conventions
automatically find the prior repo based on that). That tap also includes
prerelease unstable versions that can be obtained with "
P.S. There seems to be no *`clojure --version`* flag. Should this be
added to the command line tool?
On Mon, Aug 10, 2020 at 4:58 PM Alan Thompson wrote:
> Hi. Just helped a colleague debug a vexing problem on a CLJS project
> using Figwheel.Main.
>
> If we do *`brew install clojure/tools/cl
Hi. Just helped a colleague debug a vexing problem on a CLJS project using
Figwheel.Main.
If we do *`brew install clojure/tools/clojure`*, it works:
~/work/tmp810/xanadu > clj --help
Version: *1.10.1.561*
Usage: clojure [dep-opt*] [--] [init-opt*] [main-opt] [arg*]
clj [dep-opt*] [--
23 matches
Mail list logo
