Re: Proposed New Structure (starter for 10)

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 <[email protected]> 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 <[email protected]> wrote:
>
>> 
>> Lee Hinman <[email protected]> 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
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/jdee-devel

------------------------------------------------------------------------------