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 <udalrich.scher...@gmail.com> 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 <phillip.l...@russet.org.uk>
> 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 <lan...@mailc.net> 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 <phillip.l...@russet.org.uk>
>> 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 <lan...@mailc.net> 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 <phillip.l...@russet.org.uk>
>> wrote:
>> >>>
>> >>>> Troy Daniels <udalrich.scher...@gmail.com> 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
>> >>>> jdee-devel@lists.sourceforge.net
>> >>>> https://lists.sourceforge.net/lists/listinfo/jdee-devel
>>
------------------------------------------------------------------------------
_______________________________________________
jdee-devel mailing list
jdee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jdee-devel
