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
