cider-nrepl
cider-nrepl copied to clipboard
clojure-emacs
Add source artifacts to classpath
Is there interest in making the lein plugin automatically add source jars to the classpath?
One possibility is to add source coordinates to the :dependencies, but since most artifacts in the clojure world don't have source jars, that could be a problem. The second option is to add locally available source jars (and rely on lein pom; mvn dependency:sources; to download them).
Ritz contained code to add locally available source jars: https://github.com/pallet/ritz/blob/develop/lein-ritz/src/lein_ritz/add_sources.clj
The ritz code added the artifacts via a hooke, which is probably not the nicest way of doing it, as the source artifacts could end up in an uberjar.
I was thinking this would be a good idea. We would probably do it through the project-middleware, not a hook.
We could add a task to download available source jars (with necessary checks/fallbacks), and then use the locally available ones at runtime.
It would be up to the user to prevent them from getting included in the jar. (add plugin to :dev/:user profile only).
Though looks like at least downloading the deps is trivial with maven, we could skip that work: http://stackoverflow.com/a/14395560/2559313
@gtrak not sure what to take from that link. Source jars are mainly for java libraries (eg, clojure itself, etc).
Ah, sorry, I didn't notice before now that you had already listed the procedure for getting source deps through maven. That link's just redundant.
I like the idea of automating this, but should point out that CLJ-1161 continues to be a stumbling block here. Essentially, the sources dep that will be most widely used (Clojure itself) has a bug that, until fixed, will cause the REPL on error on startup. Until this is addressed, we can't make automatically injecting this jar the default behavior -- it would break everybody's setups.
Might it be possible to work around this by ensuring the sources jar is after the main jar on the classpath?
As long as the classloader in use respects that order, yes, that should work.
For the sake of clarity: The error originates here when the resource clojure/version.properties resolves to the invalid and erroneously included one in clojure-1.6.0-sources.jar instead of the intended one in clojure-1.6.0.jar. If we can guarantee the valid one is resolved, we avoid the error.
If we automate it at runtime instead of lein-time, loading the dependencies automatically with aether or dynapath, then we can trade off that issue for other ones :-).
FWIW, adding Clojure's sources for 1.8 works for me:
:profiles {:dev {:dependencies [[org.clojure/clojure "1.8.0" :classifier "sources"]]}}
I'm sorry for arriving late to the party, but don't we already support jumping to source out-of-the-box? What's being requested by this issue?
@Malabarba You can only jump to jars listed on the classpath. I opened this CIDER issue when I forgot about that, so I suspect others are confused too.
@expez I understand the issue you had. It sort of looks like @hugoduncan was talking about sources for clojure artifacts. Which is strange to me, given that most clojure artifact already come with sources AFAIK.
Which is strange to me, given that most clojure artifact already come with sources AFAIK.
Not sure about Clojure artifacts, but this is definitely not the case with Java ones. There are always separate source artifacts for them.
Is that this issue was is then? Trying to pull in java sources by default? Sorry, I'm just trying to determine whether the issue is still relevant.
I'm not a mindreader, but I believe so. I remember that when I was a Java dev Eclipse and Intellij would do this for maven projects - automatically fetch the sources, so their xref functionality would work for third-party code. This was pretty handy.
Hi all, I'd really love to see this resolved.
Pomegranate (now used by leiningen) hints at the intention of adding support for downloading source/javadoc jars (and adding them to the classpath).
I've been using several java libs recently, and the lack of doc/jump to source has been causing me a lot of pain. So I've decided to hack together a proof of concept and, while it's far from perfect, it seems to work fine from the repl.
What would it take to get something like it added to cider-nrepl?
What would it take to get something like it added to cider-nrepl?
Make it generally useful and open a PR. Then be patient during a short period of intense nit-picking ;)
Fwiw this is one of the bigger pain points for me too these days.
@bbatsov I'm afraid I think this is a bit beyond my powers to tackle. If anyone is willing to babysit me a bit, I'm happy to continue working on it though!
I've made a leiningen plugin as a proof of concept: lein-pocketbook.
As far as I can tell, it works, but it's pretty hacky.
I haven't done much in terms of integrating it with emacs. From a clojure file, jumping to a java source works, but, once you're in java, you can't jump around anymore (I'm hoping this is reasonably easy to achieve).
@vise890 jumping around in java could be left to another extension. Your pocketbook plugin works really well, with the caveats you mentioned considered. I was able to use them for jumping around stacktraces, even into the clojure source code: it was really magical!
@SevereOverfl0w I'm glad you enjoyed it!
I'm pretty sure the jumping around in Java just needs support on the Emacs side. Using M-x cider-find-var and inputting a fully qualified Java "symbol" already seems to be able to jump to pretty much anything.
Anyway. Do people want a PR to this repo? I can cook something up..
@vise890 If you just enable cider-mode on the Java buffer, you should be able to jump around as you like. This was how Java source support originally worked, and jumping around Java sources was a baked-in feature.
Of course, cider-mode has evolved quite a bit since then, so maybe a minimal minor mode to just support jumping would be the way to go.
I think this is still a useful suggestion and would be great to have an easy way how to add source artifacts for all java deps on the classpath. Especially for interop-heavy stuff it's invaluable - this is an area where Cursive is so much better.
Mulling over this problem, it seems like updating the dependencies coordinates before lein does dependency resolution is the simplest solution.
However, you can't just specify extra coords for the "sources" and "javadoc" classifiers, as any missing jars for those classifiers causes lein to throw an error.
I tried specifying :optional true for the deps that don't have source/javadoc jars, but that didn't stop lein from throwing errors of the form
Could not find artifact nrepl:nrepl:jar:sources:0.6.0 in central (https://repo1.maven.org/maven2/)
Could not find artifact nrepl:nrepl:jar:sources:0.6.0 in clojars (https://repo.clojars.org/)
Could not find artifact nrepl:nrepl:jar:javadoc:0.6.0 in central (https://repo1.maven.org/maven2/)
Could not find artifact nrepl:nrepl:jar:javadoc:0.6.0 in clojars (https://repo.clojars.org/)
I'm hoping someone might have thoughts on how to automatically handle this case, so that user intervention can be minimized. I'm also very curious how Eclipse and Cursive handle this problem. Perhaps they just try to resolve these deps every time 🤔
It doesn't need to be out of the box. There could be a yes/no prompt or a variable to add the source jars if needed. If some people will want to save time on this, let they do it.
Also java disassembler would be handy too, but it would require more work. IntelliJ disassembles JAR's byte code if there are no sources in the project dependencies. They don't bother to download it. I can easily load and decompile minecraft.jar and they will display obfuscated source code because symbols are erased.
And jump to java source doesn't work for me even if I include them this way: https://github.com/clojure-emacs/cider-nrepl/issues/64#issuecomment-219307373. An issue related to this is closed: https://github.com/clojure-emacs/cider/issues/1666. I guess nobody does this kind of development here. It's probably either ClojureScript or purity.
I use Spacemacs develop/5e037c889
Emacs 26.3
cider/cider-nrepl "0.25.0-SNAPSHOT"
The first thing that popped up after installing IntelliJ an putting the deps is whether I'd like that Gradle wrapper would decompile the JAR. Here you go. And it downloaded the sources for the other JAR that had those in maven central.
@Invertisment I essentially gave up and waiting if/until cider gets better support. In the meantime, I keep myself saying that I'll switch to Cursive if absolutely necessary. It turns out that I rather rarely absolutely need these things although it would be quite convenient to be able to explore Javadoc and sources without having to manually look them up on the Internet.
I also keep InteliJ IDEA opened and if I have to look at Java class I just open it there.
Those looking for browsing java sources, disassembler, debugging java source might use: https://github.com/emacs-lsp/dap-mode/wiki/Clojure:-debugging-and-introspecting-Java-Code
@Invertisment @jumarko I understand your frustration, but you have to understand that this mostly depends on the tool used to start the REPL. To my knowledge there's no easy way to tell Lein/Boot/tools.deps to just fetch every source jar that exists. If we could do this that'd be the best solution. We can explore hot loading source jars, but we still can't know whether some tool publishes those or not.
@futuro Highlights the problem here very well:
However, you can't just specify extra coords for the "sources" and "javadoc" classifiers, as any missing jars for those classifiers causes lein to throw an error.