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.
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. 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. 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. Pants seems an obvious choice,although I do not have any experience with it. Does this all make sense? Troy On Fri, Oct 16, 2015 at 6:24 AM, Przemysław Wojnowski <espera...@cumego.com> wrote: > Hi. > > It's true that I haven't done anything in JDEE for a few weeks. I have a > day job and wife, so such pauses are inevitable. But I'm here and haven't > lost > interest in working on JDEE. :-) > > Anyway, I started work on font locking and will continue that. Writing > tests > for this part turned out to be easy. > > In emacs-devel list there is a discussion about IDE features in Emacs. > After > Eric Ludlam's explanation of EDE featuers it makes sense (at least to me) > to > try to configure it for a Java project. So, I plan to work on that in the > nearest feature. > > Also CEDET's Semantic with SRecode seems like a good way to implement (at > least > some) refactoring support. So, would like take a look at that. > > Later or sooner I would like to work on Phil's "proof-of-principle". > > Regarding your last question: besides location of files (and some tests), > not > much has changed since move from SF. Most of the work has been done to > split project into two separate parts (elisp and java), which allowed to > add elisp part into MELPA. > > Cheers, > Przemysław > > W dniu 14.10.2015 o 05:25, Troy Daniels pisze: > >> It seems there was a burst of design discussion and some prototyping a >> month or >> two ago, which has died down to nothing recently. I'm using this at >> work, and >> having something that is able to figure out the project structure from >> Maven >> would be really useful. Useful enough that I would be willing to put >> some time >> into helping develop the capability. Do we have a clear idea of what we >> want to >> do, what has already been done and what is needed? If we do not have a >> clear >> roadmap on this, can someone give me a statement of what the current >> state is, >> which will be faster than me looking through the new code to understand >> what it >> does, and missing an important part because I don't understand it? >> >> Troy >> >> On Fri, Sep 4, 2015 at 7:33 AM, Phillip Lord <phillip.l...@russet.org.uk >> <mailto:phillip.l...@russet.org.uk>> wrote: >> >> Przemysław Wojnowski <espera...@cumego.com <mailto: >> espera...@cumego.com>> >> >> writes: >> >> > W dniu 27.08.2015 o 09:45, Phillip Lord pisze: >> >> BTW, I hooked up the classpath browser last night. The CIDER >> classpath >> >> browser isn't very good yet, but it works out-of-the-box. >> >> >> >> M-x jdee-live-jack-in (and wait!) >> >> M-x cider-classpath >> >> >> >> Which I guess is my proof-of-principle complete. >> >> >> >> Phil >> > >> > For me it's hard to tell whether nrepl is good or not, because I >> don't know it >> > well (I only use CIDER), but at least it works and has support, so >> seems ok for >> > our purpose. >> >> You may have seen some of the recent chatter on github with Sam >> Halliday. >> >> https://github.com/jdee-emacs/jdee/issues/20 >> >> Using an ensime client/server set up also seems an option. It's doing >> something similar, but sending JSON across the wire. In that case the >> "middleware" layer is in Scala, although, of course, all these JVM >> hosted languages can be made to work together. >> >> > JVM side will need to be improved, because now `cider-classpath' >> shows classpath >> > of Maven+CIDER+Project, but should be only Project. >> >> Yeah, I think that is true. >> >> >> > >> > Anyway, IMHO we can go in that direction. >> > >> > Regarding naming, as all "Clean code" books tell, it should be >> intent revealing >> > name, maybe something like jdee-jvm-connector, jdee-jvm-bridge, etc. >> > "live" (or even "jive" :-) ) doesn't tell much, hence hinders >> understanding. >> >> It's possible, I guess. I didn't want something as long as that, >> because >> it will hinder modularisation at the other end. I mean I want to avoid >> things like this. >> >> (provide 'jdee-jvm-connector-import) >> >> (defvar jdee-jvm-connector-import-is-this-long t >> "Non-nil iff the variable name is long") >> >> CIDER has the same issue, I feel. So, open to suggestions. jdee-jvm >> is possible. >> >> > Sorry for late reply. :-| >> >> No worries. My plan would be to look at import functionality soon, as >> this will require new middleware which I haven't done so far. So, we >> would end up with new functions like. >> >> jdee-live-import >> jdee-live-import-all >> >> These would obviously duplicate what is already in jdee-import. That's >> kind of deliberate. It would give some idea of the code that is needed >> to achieve this. >> >> Phil >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> jdee-devel mailing list >> jdee-devel@lists.sourceforge.net <mailto: >> 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
