Re: Proposed New Structure (starter for 10)

I really don't see much downside to leaving CIDER a dependency.  Development of JDEE via cider/Clojure I think would be much faster and it has a solid development community.  Is the proposed change to nrepl-client.el going to be merged and maintained in the CIDER code base?  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.


On Aug 26, 2015, at 8:20 AM, Phillip Lord <[email protected]> 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 <[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


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