On Aug 26, 2015, at 9:25 AM, Phillip Lord <phillip.l...@russet.org.uk> wrote:
> Paul Landes <lan...@mailc.net> writes: > >> If it's a fork we might want to think about just staying with CIDER >> indefinitely. >> >> I agree about CIDER--worked with it quit a bit and it is solid. To reiterate >> what you mentioned earlier it already gives a lot of what JDEE needs (i.e. >> javadoc, source etc). >> >> I also very much agree with letting the build tool manage (class/source) >> paths, which would lead to wacking a lot of code and a simpler JDEE. > > At the moment, I am concerned about how the build tool should be > launched. Maven, for example, is quite tricky to launch from within a > running JVM. So, I am not clear where, for example, "compile" > functionality should go -- JDEE as is (via an external process) or > jdee-live (via direct JVM invocation). > This is where it gets complicated. The compilation (generation of classes) can be done via maven in the running JVM process, but then using the generated .class files become a mess regardless of the language used on top of the JVM because it is a JVM class loading issue itself. Class loaders are hung on to (technically only as long as the class has a reference count but I've seen this not to be the case) and old versions of classes linger. Classes referenced across loaders create signature and no class def exceptions etc. This is why I wanted to find a way to use the Java source itself (not the .class file with reflection/introspection) for all class generation, wizard etc code JDEE currently uses beanshell for. Clojure seems to do a good job of handling this, but I'm not sure what they do with old versions of classes for functions/files that get recompiled. That said, they're going directly for Clojure to byte code so it's a little different. I started to look at Clojure's dynamic class loader but got lost in the weeds and no documentation made it more difficult. > Incidentally, I was thinking of renaming jdee-live again to "jive" just > for shortness. > Not sure that's a great idea. >> >> >> On Aug 26, 2015, at 8:20 AM, Phillip Lord <phillip.l...@russet.org.uk> wrote: >> >>> >>> There is a dependency on cider, yes. >>> >>> My initial feeling was that this could be a short term dependency till >>> nrepl-client.el was wound out, but in practice, I am using cider for >>> other things. As well as programmatic JVM access (for Emacs to use), it >>> also provides a nice shell for users to access the JVM directly. And a >>> significant amount of the middleware and UI is going to be useful to >>> both. >>> >>> I've also been looking a malabar mode, though, and I do wonder whether I >>> am achieving anything that is not already there. It's an open question I >>> think. >>> >>> The other question is one about data -- I believe that we should reduce >>> the number of things that JDEE knows about as far as possible -- >>> classpath for instance, and leave that to the build tool (whether that >>> is maven, ant or gradle). But this is a big change and one likely to >>> have many implications. >>> >>> >>> >>> Paul Landes <lan...@mailc.net> writes: >>> >>>> So there is no dependency on Cider? >>>> >>>> I'll take a look at some point soon as I'm up to my ears in work. >>>> >>>> >>>> On Aug 25, 2015, at 5:17 PM, Phillip Lord <phillip.l...@russet.org.uk> >>>> wrote: >>>> >>>>> >>>>> Lee Hinman <leehin...@fastmail.com> writes: >>>>>>> I have advanced this somewhat now and would be interested in opinions. >>>>>>> I now have a worked nREPL connection to a live JVM running over the >>>>>>> project. This provides the equivalent of the "beanshell interpreter" >>>>>>> from a user perspective (i.e a shell) and can also be used to drive >>>>>>> JVM interaction for things like introspection. >>>>>> >>>>>> I took a look, looks cool and seems to work! >>>>> >>>>> Good! >>>>> >>>>>> >>>>>>> Unlike, beanshell, I think we can easily support class reloading (i.e. >>>>>>> live update the JVM for newly compiled classes), and extension of the >>>>>>> classpath (so we can add new maven dependencies without restarting). >>>>>>> We should be able to steal a lot of work from Cider (it's stacktrace >>>>>>> support is nice!). >>>>>> >>>>>> Something that will have to be ironed out is redirection of streams, I >>>>>> noticed that Standard Out went into the *Messages* buffer, but that >>>>>> shouldn't be too hard to hook up. >>>>> >>>>> Actually, that's a fake! Standard Out actually goes to a process buffer. >>>>> I just "tee" it to the *Messages* buffer so I can see what it says. >>>>> >>>>> I need to do something more intelligent, I agree. In the ideal world, it >>>>> should be silent if it works, and popup a buffer if it crashes. >>>>> >>>>> >>>>> >>>>>>> The build is a little baroque at the moment, although it requires only >>>>>>> standard tools, so is clean. From a user perspective, it will require >>>>>>> maven, but no other downloads (once it's on Maven central). It's maven >>>>>>> agnostic, though, so we *should* be able to support gradle, ant, any >>>>>>> other build system or none with a little work. >>>>>> >>>>>> I opened a comment for the only issue I ran into when installing this >>>>>> here: https://github.com/phillord/jde-with-clojure-backend/issues/1 >>>>> >>>>> Fixed there. >>>>> >>>>> >>>>>>> I've renamed jde-interactive to jdee-live and removed my minimal ELPA >>>>>>> compliant minimal jde as that is pointless now. My plan for the future >>>>>>> is to get one vaguely useful tool working, so I can test interaction >>>>>>> with the Clojure based middleware, then stop, until it is clear that >>>>>>> this is the way forward. >>>>>>> >>>>>>> Thoughts welcome! >>>>>> >>>>>> Thanks for the work, I think this looks great so far, hopefully it can >>>>>> be make useful here soon! (to me, useful means I can compile or check >>>>>> compilation from a Java buffer) >>>>> >>>>> Compilation is a reasonable aim. I am trying to put "pomegranate" into >>>>> place, so I can extend the classpath on-the-fly. After that, "compile" >>>>> seems a reasonable aim, although this means I have to interact with >>>>> maven to get it to launch the compile goal. Guess what? There are >>>>> several different ways to do it and the documentation is rubbish for all >>>>> of them. Maven, maven, maven. I might give up and see if cider >>>>> completion code (middleware or emacs client) is reusable instead. >>>>> >>>>> Anyone else? I don't want to carry on with this for too long if I am the >>>>> only one who thinks it makes sense. >>>>> >>>>> 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
