Fork me on GitHub
#tools-deps
<
2021-02-17
>
alexmiller22:02:50

Clojure CLI tools 1.10.2.786 are now available in a prerelease * https://clojure.atlassian.net/browse/TDEPS-56 - fix main-opts and jvm-opts splitting on space

šŸ„³ 3
alexmiller22:02:46

This fixes the long-standing issue with space splitting necessitating the Corfield comma. I tested on both Mac and Windows, but I would really appreciate anyone kicking the tires on this.

šŸ™Œ 3
alexmiller22:02:00

the .jvm and .main cache files are now in a different format (arg per line instead of space-separated args in a single line), but simply installing a new version of the CLI installs a new root deps.edn, which is part of the cache staleness check, so all existing cached files should be considered stale and the recomputed cache file should just happen automatically. I re-tested that too across the install boundary but again, more eyes welcome.

seancorfield22:02:33

Nice! I look forward to being regulated to the annals of history as a Clojure curiosity! :rolling_on_the_floor_laughing:

šŸ™‚ 6
alexmiller22:02:46

you never when the Corfield comma will strike again

alexmiller22:02:09

the next conf you go to, you should just wear a shirt with a big comma on it

šŸ˜‚ 16
seancorfield22:02:03

Imma stealin' that idea! šŸ™‚

andy.fingerhut22:02:32

People may think you have joined the Tres Comas club (Silicon Valley TV show reference)

andy.fingerhut22:02:39

if you have 3 commas on the shirt

ghadi22:02:27

pour one out for a brilliant hack šŸ·

seancorfield22:02:44

I put a Jira issue on our board to switch up to 1.10.2.786 but it probably won't happen until tomorrow. I'll report back.

seancorfield22:02:50

(right now I'm dealing with an edge case I discovered today when we switched from the CLJ_CONFIG hack to the generate-`deps.edn` hack... annoyed I missed this when I switched over a while back!)

alexmiller22:02:32

I am also deep into considering a major change in the git impl (thanks @ghadi) which may also "fix" a slew of the outstanding git/ssh issues, hoping to get more time on that on Friday

alexmiller22:02:19

and of course, some new stuff :)

borkdude22:02:43

Is it the shelling out to git branch which ghadi made or something else?

alexmiller22:02:52

I'd like to release the current set of changes as stable before I push that into the prerelease though

borkdude22:02:49

cool. I used that in tools-deps-native as well, when I had problems compiling jgit, worked great. later on I managed to get it working as is though. just fyi.

alexmiller23:02:55

There is a tools.gitlibs branch for it now that incorporates some additional changes. Iā€™m going to do some more work on the error handling still

alexmiller23:02:39

Good to know

seancorfield23:02:05

I'm working with t.d.a. 0.9.871 as a library, trying to resolve a specific set of deps and I'm getting this error:

{:clojure.main/message
 "Execution error (ArtifactNotFoundException) at org.eclipse.aether.internal.impl.DefaultArtifactResolver/resolve (DefaultArtifactResolver.java:414).\nCould not find artifact org.apache:apache:pom:13\n",
 :clojure.main/triage
 {:clojure.error/class
  org.eclipse.aether.transfer.ArtifactNotFoundException,
  :clojure.error/line 414,
  :clojure.error/cause
  "Could not find artifact org.apache:apache:pom:13",
  :clojure.error/symbol
  org.eclipse.aether.internal.impl.DefaultArtifactResolver/resolve,
  :clojure.error/source "DefaultArtifactResolver.java",
  :clojure.error/phase :execution},
 :clojure.main/trace
 {:via
  [{:type org.eclipse.aether.resolution.ArtifactDescriptorException,
    :message
    "Failed to read artifact descriptor for org.apache.httpcomponents:httpcore:jar:4.4.5",
    :at
    [org.apache.maven.repository.internal.DefaultArtifactDescriptorReader
     loadPom
     "DefaultArtifactDescriptorReader.java"
     301]}
   {:type org.apache.maven.model.resolution.UnresolvableModelException,
    :message "Could not find artifact org.apache:apache:pom:13",
    :at
    [org.apache.maven.repository.internal.DefaultModelResolver
     resolveModel
     "DefaultModelResolver.java"
     176]}
I can depend on org.apache.httpcomponents/httpcore {:mvn/version "4.4.5"} just fine from the CLI and other contexts but I'm at a bit of a loss to know where to start digging for this error...

seancorfield19:02:29

I eventually figured out my problem this morning: in building the basis using t.d.a I had managed to "lose" the :mvn/repos key when I was combining deps hash maps and so it was working if the local ~/.m2 repo contained the artifact but not if the artifact needed to be pulled from Maven Central facepalm -- so it was behaving differently on different machines, depending on what was already downloaded šŸ˜ž

picard-facepalm 8
facepalm 4
seancorfield23:02:32

I can't resolve org.apache/apache "13" via the CLI tho' so at least that part checks out (I found it on Maven and looks like it might just be a pom but the error above says it can't resolve that either...)

seancorfield19:02:29
replied to a thread:I'm working with t.d.a. 0.9.871 as a library, trying to resolve a specific set of deps and I'm getting this error: {:clojure.main/message "Execution error (ArtifactNotFoundException) at org.eclipse.aether.internal.impl.DefaultArtifactResolver/resolve (DefaultArtifactResolver.java:414).\nCould not find artifact org.apache:apache:pom:13\n", :clojure.main/triage {:clojure.error/class org.eclipse.aether.transfer.ArtifactNotFoundException, :clojure.error/line 414, :clojure.error/cause "Could not find artifact org.apache:apache:pom:13", :clojure.error/symbol org.eclipse.aether.internal.impl.DefaultArtifactResolver/resolve, :clojure.error/source "DefaultArtifactResolver.java", :clojure.error/phase :execution}, :clojure.main/trace {:via [{:type org.eclipse.aether.resolution.ArtifactDescriptorException, :message "Failed to read artifact descriptor for org.apache.httpcomponents:httpcore:jar:4.4.5", :at [org.apache.maven.repository.internal.DefaultArtifactDescriptorReader loadPom "DefaultArtifactDescriptorReader.java" 301]} {:type org.apache.maven.model.resolution.UnresolvableModelException, :message "Could not find artifact org.apache:apache:pom:13", :at [org.apache.maven.repository.internal.DefaultModelResolver resolveModel "DefaultModelResolver.java" 176]} I can depend on `org.apache.httpcomponents/httpcore {:mvn/version "4.4.5"}` just fine from the CLI and other contexts but I'm at a bit of a loss to know where to start digging for this error...

I eventually figured out my problem this morning: in building the basis using t.d.a I had managed to "lose" the :mvn/repos key when I was combining deps hash maps and so it was working if the local ~/.m2 repo contained the artifact but not if the artifact needed to be pulled from Maven Central facepalm -- so it was behaving differently on different machines, depending on what was already downloaded šŸ˜ž

picard-facepalm 8
facepalm 4