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
