Added find-resources #45

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants
Contributor

Chouser commented Dec 4, 2012

When tracking down a library version problem yesterday, we found it useful to be able to look at all the jars on the classpath that included a particular .clj file. This allowed us to see we were loading it from a different .jar than we expected. Pomegranate seems a natural place to have a function that makes this easy.

For example, here's what I get when I nrepl-jack-in from the pomegranate project itself:

(find-resources "clojure/core.clj")
;=> ("jar:file:/home/chouser/.lein/self-installs/leiningen-2.0.0-preview8-standalone.jar!/clojure/core.clj" "jar:file:/home/chouser/.m2/repository/org/clojure/clojure/1.4.0/clojure-1.4.0.jar!/clojure/core.clj" "jar:file:/home/chouser/.m2/repository/org/clojure/clojure/1.3.0/clojure-1.3.0.jar!/clojure/core.clj")

Owner

cemerick commented Dec 4, 2012

I like the objective, but I don't think the implementation is quite right:

=> (find-resources "java/util/UUID.class")
()

By limiting the search to URLClassLoaders will limit results significantly. I think you can just use ClassLoader.getResources, as long as you distinct the results. You may need to fiddle with the order of those results before or after they go through distinct in order to ensure correspondence with clojure.java.io/resource.

Contributor

Chouser commented Dec 5, 2012

Excellent point. .getResources does seem to be closer to what we want.

Reversing the classloaders (as get-classpath does) and then running the
URLs through "distinct" appears to be correct in my limited tests. I'm
wary of messing with the return order any more than that -- actually of
messing with it even that much. When this is used as a debugging aid,
hiding details can be the source of more confusion.

Having said that, returning a seq of URLs that contains dups doesn't seem
very useful, so the only alternative to "distinct" that occurs to me is to
return a map of classloaders to their resources. What do you think?

Owner

cemerick commented Dec 5, 2012

I really like the idea of the map of classloaders => resources. That could end up being even more useful than you'd expect, e.g. making it possible (though perhaps slightly insane) to infer which classloader should be the parent of a new classloader that should have access to this library, but not that one.

It sounds like there's actually two functions needed:

  • One that returns a seq of pairs, [classloader seq-of-urls].
  • Another that uses the results of the first to produce the flattened seq of urls, ordered and distinct as appropriate.

Are you up for a fourth attempt? (note, you should be able to update existing pull requests)

Chouser closed this Dec 6, 2012

Chouser reopened this Dec 6, 2012

Contributor

Chouser commented Dec 6, 2012

Apparently the "close" button doesn't mean "close this comment box"

cemerick closed this in 2ae9213 Feb 20, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment