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> wrote: > Przemysław Wojnowski <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 > 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
