Re: [jdee-devel] Proposed New Structure (starter for 10)
Brought to you by:
paullandes
From: <phi...@ru...> - 2015-10-27 10:38:29
|
That's straight-forward, since the JVM knows about the classpath. In fact, it should work already. I *think* calling (cider-classpath) should do this for the current-buffer. If I remember correctly, the stacktrace handling from cider works as well. At least, those are the two bits of middleware that I have added direct from cider. The issue with source is that the running JVM doesn't need to know where the source code is -- this is not an issue in Clojure since (generally), the JVM *does* know where the source code is. Still, there are some pretty obvious heuristics to find the source, especially as the class name gives you the filename. Phil Troy Daniels <uda...@gm...> writes: > We also need to know about the classpath, so we can do completion and > imports. Although tying in the classpath is the main focus of what I am > doing at the moment. > Troy > > On Mon, Oct 26, 2015 at 12:43 PM, Phillip Lord <phi...@ru...> > wrote: > >> >> Yes, if I wanted to make a standalone jar, that's how I'd do it. For use >> within ant or from a shell-script/batch this would be a good way to go. >> For projects already using maven, then I'd leave it as. >> >> For me, at the moment, though, this is not an issue. My code is not >> maven-centric, it's just where I have started. Support other mechanisms >> of launch I do not think is hard. >> >> As I have said, the issue comes when we need to know about stuff >> the project knows about, but the JVM doesn't -- source paths being the >> obvious one. Are there many other settings like this? At the moment, I >> don't know for sure, but nothing leaps to mind. >> >> >> >> >> Paul Landes <la...@ma...> writes: >> >> > If we're tightly coupling with clojure we _could_ also make it a >> leiningen >> > project, bake in the repl (add deps and API call in main) and compile an >> AOT >> > uberjar. >> > >> > >> > On Oct 26, 2015, at 6:56 AM, Phillip Lord <phi...@ru...> >> wrote: >> > >> >> >> >> >> >> It's worth noting that the only thing I am using maven for is pulling in >> >> the clojure dependencies and launch the JVM with the appropriate project >> >> settings. >> >> >> >> Getting another build tool to do the same thing would be >> >> straight-forward enough. Even a shell script would work with a prebuilt >> >> jar (of clojure and the nrepl server). The current code is not really >> >> maven-centric. I just happen to have used maven. >> >> >> >> Phil >> >> >> >> Paul Landes <la...@ma...> writes: >> >> >> >>> I agree with Phillip writes and add that supporting two back ends at >> >>> this point would be burdensome. >> >>> >> >>> For those that dislike maven there isn't any reason some template >> config (pom) >> >>> file couldn't be used in a temp directory (or even memory). Either way >> it >> >>> would be pretty small since at best you'd only be (re)configuring the >> >>> source/build/test paths. >> >>> >> >>> >> >>> On Oct 23, 2015, at 4:00 AM, Phillip Lord <phi...@ru...> >> wrote: >> >>> >> >>>> Troy Daniels <uda...@gm...> writes: >> >>>> >> >>>>> I checked out the clojure backend branch last night and played >> around with >> >>>>> it some. I had some trouble getting it to build, but eventually >> solved >> >>>>> those problems. I submitted a pull request with the changes I made, >> if you >> >>>>> want to incorporate them. >> >>>> >> >>>> Bit spammed at the moment, but will do this. I tend not to use melpa >> >>>> but melpa stable, though, so there many be some version issues. >> >>>> >> >>>> >> >>>>> I'd like to start integrating this into the main code base. >> >>>>> >> >>>>> I did have an idea for transition as well. The code that Phillip >> wrote is >> >>>>> maven-centric, and will not work without additional effort in a >> project >> >>>>> with an ant build, or various other build tools. So my idea was to >> use the >> >>>>> nrepl if we can find a pom file, but otherwise fall back to the >> existing >> >>>>> code. This also means that functionality can be converted piecemeal. >> >>>> >> >>>> This sounds reasonable, but I would say that maintaining two backends >> is >> >>>> going to be a pain. I've tried in my code to separate out the >> >>>> "maven-centric" and "everything else" part. This is why "jde-nrepl" is >> >>>> in a different package. >> >>>> >> >>>> Ultimately, I think a decision needs to be made. If this is the root >> we >> >>>> go, then I would say it should be on the basis that we move >> >>>> functionality out of the existing setup and into the clojure based on. >> >>>> >> >>>> An alternative transition path would be to run beanshell from inside >> the >> >>>> clojure middleware. Not thought that through, but maybe it would work. >> >>>> >> >>>> >> >>>>> For example, there is a cider function to get the classpath, so >> >>>>> replacing jdee-*-classpath is fairly simple. Replacing the import and >> >>>>> completion functionality is more complicated, so would take longer to >> >>>>> replace. >> >>>> >> >>>> One issue I have is whether to run nrepl in the project environment or >> >>>> the maven environment. Unfortunately this makes a difference -- maven, >> >>>> for example, knows about source locations while the project does not >> (it >> >>>> only needs the classpath). >> >>>> >> >>>> >> >>>>> Phillips branch also has three (non-test) projects in a single >> repository: >> >>>>> java, lisp and clojure. I think this makes sense for several >> reasons. It >> >>>>> makes it obvious which version of the java code works with which >> version of >> >>>>> the lisp code. It also makes it simple to package the jars and >> clojure >> >>>>> with the lisp code to put on MELPA. It would be good to have >> something >> >>>>> better than the current top level build script, which is just a shell >> >>>>> script. >> >>>> >> >>>> Actually, there's a bunch of make files in there which work pretty >> well. >> >>>> >> >>>> >> >>>>> Does this all make sense? >> >>>> >> >>>> It does. >> >>>> >> >>>> Phil >> >>>> >> >>>> >> ------------------------------------------------------------------------------ >> >>>> _______________________________________________ >> >>>> jdee-devel mailing list >> >>>> jde...@li... >> >>>> https://lists.sourceforge.net/lists/listinfo/jdee-devel >> |