Fork me on GitHub

@alexmiller bit of a weird one no repro yet exactly, but it looks like RepositorySystem is coming back as nil. I don't suppose you're clued up on this and can think of an obvious cause?

Alex Miller (Clojure team)17:10:29

I looked at that when it was filed as it was mentioned here too. It's weird, don't know what to make of it. I think from the stack this pre-dates the session cache additions?


It's still happening after updating too.


Digging in, the impl of the service locator does attempt to add the repository system, so that should be there.


Bumping from 1.1.1 of the maven dependencies to 1.4.1 doesn't fix it either.


this is the problem with service locators. All the damn coupling.

Joe Lane17:10:13

Hey friends, I'm having an issue cloning my own private github repo with tools deps. Even though I'm able to clone the repo with the ssh url into a local tmp directory, JGit is still telling me that Caused by: org.eclipse.jgit.errors.TransportException: [email protected]:Dept24c/random.git: USERAUTH fail. I'm on a mac with these version numbers:

Joes-MacBook-Pro:snapestry-ion magemasher$ clj -Sverbose
version      =
install_dir  = /usr/local/Cellar/clojure/
config_dir   = /Users/magemasher/.clojure
config_paths = /usr/local/Cellar/clojure/ /Users/magemasher/.clojure/deps.edn deps.edn
cache_dir    = .cpcache
cp_file      = .cpcache/479583893.cp
The ssh key I have on github matches this key below:
ssh-add -l -E md5
4096 MD5:10:ef:06:6b:9b:94:86:fc:06:83:9f:17:0a:8c:bb:10 /Users/magemasher/.ssh/id_rsa_jplane (RSA)
Does anybody have any ideas? I'm really stumped here.

Joe Lane17:10:39

(I just confirmed by starting it, same failure)

Alex Miller (Clojure team)18:10:33

there are some known failure modes with host key algorithms etc, but this doesn't really look like that

Alex Miller (Clojure team)18:10:42

I assume you can git clone with that key


Do you have entries in .ssh/config ?


Sometime jsch tries to read those instead of the ssh agent

Joe Lane18:10:03

I do, are they safe to paste?


It’s usually just file names

Alex Miller (Clojure team)18:10:32

there's one like IdentityKey or something that might need to be removed

Joe Lane18:10:45

Host *
  AddKeysToAgent yes
  IdentityFile ~/.ssh/id_rsa_jplane
  IdentitiesOnly yes

  User admin
  IdentityFile ~/.ssh/id_rsa_jplane

Alex Miller (Clojure team)18:10:01

yeah, remove the IdentityFile line in first block


Comment out the first block

Joe Lane18:10:45

Hey, it works!

Joe Lane18:10:42

(commenting out just the IdentityFile) So, the reason I had that line in there in the first place was because of these instructions.

Joe Lane18:10:34

So, while I'm glad this was fixed for me, are the github instructions conflicting with what Jsch needs?

Joe Lane18:10:07

Either way, thank you both for your assistance! I see similar advice was given by Alex on the jira issue.


The problem is, I can't figure out what would set a version resolver! There's nothing in the default service locator code.


@lanejo01 JSch is going to be a constant source of headaches


Okay. Figured out what sets the version resolver, but I don't understand how I'm getting java.lang.ClassCastException: Cannot cast org.apache.maven.repository.internal.DefaultVersionResolver to org.eclipse.aether.impl.VersionResolver when defaultversionresolver is like this:

public class DefaultVersionResolver
    implements VersionResolver, Service


Doesn't that explicitly state that it's a VersionResolver?!


Is it crossing a class loader boundary perhaps?

Alex Miller (Clojure team)18:10:40

yeah, must be same class loaded from different loader

Alex Miller (Clojure team)18:10:39

looks like you're buried in some capsule stuff - doesn't that do weird things with classloaders?

Alex Miller (Clojure team)18:10:09

or is this just setting up capsule stuff

Alex Miller (Clojure team)19:10:50

I'm not sure what the setup is, but there must be same class available via different loaders somehow here


This is setting up capsule stuff, so no classloaders involved here yet.


capsule is very good on the classloader front fwiw btw. It just extracts to a directory and runs it, much like leiningen. OneJar is the classloader one.


I'll see if I can make this a minimal repro at least. Remove pack from the equation.


rlwrap: Oops, crashed (caught SIGABRT) - this should not have happened!If you need a core dump, re-configure with --enable-debug and rebuildResetting terminal and cleaning up...
Today is not my day apparently! 🙂


that happens a lot with long lines


probably a method to constrain it. haven't looked


long like 10MB lines, in my experience


I sometimes idly wonder how many different behaviors exist among line-based utility programs for very very long lines.


What I don't understand is how simply commenting out oz would change things. How does that cause a classloader?!

Alex Miller (Clojure team)20:10:56

I don't have a theory for why this is happening, just trying to work backward from the evidence


I can't create a minimal repro either. Taking the exact pack code and placing it in another project stops it from happening... :thinking_face:

Alex Miller (Clojure team)21:10:51

can you get pack out of it? Just call tools.deps with oz stuff?

Alex Miller (Clojure team)21:10:59

I can't remember if I did that when it was logged or not


Doing that doesn't throw. There's something contextual/environmental that I am not accounting for.

Alex Miller (Clojure team)21:10:36

are you running via clj? if so, what's the classpath? Are there any uberjars such that same class has two possible sources?


Running via clj. The classpath is pretty big because of oz.


duplicates looking likely


clojure -Spath -A:pack:packit | (while IFS= read -rd: line; do jar tf "${line}"; done) | sort | uniq -d I did this and got results


I know why my repro isn't working, it's because I'm not co-locating oz and t.d.a on the classpath in my repro, but I am when I load pack into an existing project. That's also why this happens when used with add-lib.


It's nothing to do with dependency resolution (not really anyway). It's to do with the classpath tda is running under. I saw maven duplicates with the above classpath, so I'm guessing that's the root cause. Although I've never seen issues like this where one wins out over the other in different places.


the classpath isn't canonical, classloaders are, the classpath is interpreted by some classloader, so if some wants a classloader that behaves sort of like the system classloader (or whatever the root classloader is called these days) it can make a classloader that interprets the classpath but has a slightly different behavior

Alex Miller (Clojure team)22:10:33

Maven has all kinds of magic dependency injection and it’s entirely possible there is some service config somewhere that is giving weird behavior. Usually I just avoid using all of that stuff when I call the maven APIs but it’s surprisingly invasive.