Hi James,
Thanks for your e-mail, and agreed in all points. I didn't realize
that there is a JSR going on for plug-ins, it is really a good idea to take
a look at it and try to conform. Once I thought about peeking one of the
more mature plug-in APIs like OpenTools for JBuilder and try to emulate, so
that we could re-use their already made plug-ins. But that are problems with
that - you're now tied to a commercial API - so a JSR-compliant API makes
much more sense.
As for your questions:
1) I would say people and technology are the major problems (we don't have a
deadline). From my little experience in this area, anything other than very
trivial plug-ins (basically launching a Java app to process the current
buffer and capture the results) requires a fair amount of elisp knowledge.
And as far as technology, as we discussed before in this list, it is quite
hard to get the Java code to drive the control flow (allowing it to change
the contents of the buffer, change the cursor position, open new windows,
etc.). It can be done but it depends on interprocess communications, which
adds a lot of complexity. I used gnuclient for that purposes, Paul used
direct socket communication in the JDEbug. The JUCI package will I believe
address this problem in a generic way.
2) I think extending JDE is the way to go. Note that it is quite easy,
today, to integrate Emacs in many IDEs by using gnuclient.
3) As I said above, this looks like a great idea. It may be the case that we
won't be able for performance or other reasons to have a 100% Pure Java
plug-in API; but if we can, by all means it should follow a standard.
Regards,
Nascif
> -----Original Message-----
> From: James Higginbotham [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 19, 2003 12:21 PM
> To: Nic Pottier; Abousalh-Neto, Nascif [NCRTP:3X20:EXCH];
> Paul Kinnucan
> Cc: [EMAIL PROTECTED]
> Subject: RE: JDEE plugins (was JUCI)
>
>
> <snip/>
>
> > Until
> > recently I think Emacs has been unsurpassed as the editor to
> > use for Java, but I think some of the IDE's are catching up,
> > specifically IntelliJ which most people I work with use.
> > There are a few features there which I think would be easy to
> > implement as JDE plugins (especially using reflection) but as
> > Nascif says, I have neither the time or desire to brush up my
> > lisp skills to do so. If it were possible to create some
> > basic interfaces that pure Java plugins could write to I
> > think that would go a long way towards keeping us able to
> > taunt other users with our editor. :)
>
> I echo that remark.. I've been using JDE for several years
> and I have always been able to defend it vs. things like
> JBuilder, Visual Caf�, and to some extent, VAJ. But now,
> Eclipse and IntelliJ are blowing JDE away.. Now, I love Emacs
> and think its editor is far superior to all the rest. And
> until now, I've always selected Emacs + JDE over anything
> these IDEs offered - GUI Swing/servlet/ejb wizards, etc. Now,
> it seems JDE has reached the end of its extensibility until
> this plugin design is factored in. So, now that the plugin
> arch is being acknowledged as a must for JDE to grow as fast
> as the current IDEs, I have to ask:
>
> 1) What are the biggest hurdles to get JDE using this new
> plugin arch - people, time, technology?
> 2) Is going JDE, versus integrating the Emacs editor into
> today's IDEs, the right way to solve this problem (i.e. which
> is more work - redesigning JDE or bridging a native editor
> into today's popular IDEs to gain their infrastructure and
> Emacs's editing capabilities)?
> 3) Should JDE be examining and/or joining JSR-198 to see if
> we should be following this plugin API now, such that JDE
> will be compliant in the future? Thus, the JDE plugin code
> won't have to change again in a few months to allow JDE to
> take advantage of upcoming JSR198-compliant plugins?
>
> Just throwing out some comments to get the ball rolling. It
> seems everyone is up for this idea, so my hope is to get us
> thinking in the proper frame of mind, as this plugin
> architecture may require enough redesign to rethink the way
> JDE works now. I'm obviously not a JDE team member, nor have
> I done much LISP, so some or all of my assumptions could be
> slightly-to-way off. All I know is that these current IDEs
> are giving JDE a run mostly because its written in the same
> language as the programmer uses, reducing the barrier to
> entry for extending it. This plugin idea is like the right
> thing to do (and not doing it would jeopardize JDE's
> effectiveness IMO), but I want to make sure that JDE is still
> focusing on the right approach, not just taking the approach
> because that's the way its been done in the past.
>
> Best Regards,
> James
>
