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
