Re: [jdee-users] Call to Fork or simply for JDEE TODO items
Brought to you by:
paullandes
From: Eric M. L. <er...@si...> - 2013-04-30 03:10:26
|
On 04/29/2013 11:55 AM, Paul Landes wrote: > Again, I have thought about forking/canabalizing etc. The primary motivation is that the project is large and very dependent on CEDET. I have nothing bad to say about CEDET but it's current integration with Emacs post 23 has been non-compat and created a lot of issues for installation. I am a little leery about its complexity as well (maybe Eric can chime in here). Anyway I have been thinking once again about this and if there is interest I can put some diagrams together in how I'd go about doing that. Ding! (That's me chiming in.) So sure, CEDET is pretty complicated. A side effect of trying to do complicated things. CEDET was really born from the fact that Paul K. and I work together at the MathWorks and used to chat Emacs a lot. I had speedbar, and some random parser stuff for C/C++, and he had a neat project system for Java. We hashed out how the systems could work together. Paul K wrote the first Java parser, imenu interface, and even the first semantic database. I mimicked some project aspects of JDEE in EDE but we never managed to get the things merged together. That's why EDE has all those flavors, it was due to me trying to get something we could merge in those early days. Anyway, that's just a long winded way of saying that CEDET should be a solid platform for JDEE to extend. The version shipping with Emacs after the most recent update should have some of the extended Java support I added, but users would need to get CEDET from bzr to get that for older Emacsen based on the pre CEDET 1.0 flavor. I'm also happy to help with porting if I can (and when it isn't catapult season.) On a more general note, CEDET has grown in scope, so there may be new tools you could take advantage of. In particular, the srecode package could be helpful for code-gen tasks if the use of external Java template things don't pan out. It can also be used for Makefile (or any other build file) generation. Another newer feature is support for querying .jar files for symbols. For Android (what I was using at the time) it can do completion pretty reliably from almost any class in a .jar file. Others indicated it did ok for non-android Java use also. It may be you could use that to replace something currently depending on beanshell? Anyway, I read some of the threads on this tonight, and it sounds like some thought is going into updating JDEE. I find the more I post on my mailing lists, the more people start showing up and participating. I look forward to seeing JDEE grow again. Eric |