Re: Proposed New Structure (starter for 10)

Paul Landes <[email protected]> writes:

> 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.

Yes, that is my end conclusion also.

> Is the proposed change to nrepl-client.el going to be merged and
> maintained in the CIDER code base?

It wasn't so proposal as a discussion. Bozhidar was potentially
interested, less for JDEE but for non-jvm usage. But, it's not clearl
who would do the work. We certainly do not have a compelling use case
for it at the moment.

> 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).

Incidentally, I was thinking of renaming jdee-live again to "jive" just
for shortness.

Phil

>
>
> 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

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