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

Reply via email to