Hi.

It's true that I haven't done anything in JDEE for a few weeks. I have a
day job and wife, so such pauses are inevitable. But I'm here and haven't lost
interest in working on JDEE. :-)

Anyway, I started work on font locking and will continue that. Writing tests
for this part turned out to be easy.

In emacs-devel list there is a discussion about IDE features in Emacs. After
Eric Ludlam's explanation of EDE featuers it makes sense (at least to me) to
try to configure it for a Java project. So, I plan to work on that in the
nearest feature.

Also CEDET's Semantic with SRecode seems like a good way to implement (at least
some) refactoring support. So, would like take a look at that.

Later or sooner I would like to work on Phil's "proof-of-principle".

Regarding your last question: besides location of files (and some tests), not
much has changed since move from SF. Most of the work has been done to split 
project into two separate parts (elisp and java), which allowed to add elisp 
part into MELPA.

Cheers,
Przemysław

W dniu 14.10.2015 o 05:25, Troy Daniels pisze:
> 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
> <mailto:phillip.l...@russet.org.uk>> wrote:
>
>     Przemysław Wojnowski <espera...@cumego.com <mailto: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 <mailto: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

Reply via email to