Re[3]: JDEE plugins (was JUCI)
>> "Eric" == Eric M Ludlam <[EMAIL PROTECTED]> writes:
Nick Sieger <[EMAIL PROTECTED]> seems to think that:
>>> "PK" == Paul Kinnucan <[EMAIL PROTECTED]> writes:
>>
PK> Eric M. Ludlam writes:
Something I always wanted to do was use EIEIO to wrap Java
objects. EIEIO could act as a proxy for Java objects, and there
could be Java object proxies for EIEIO objects. In this world
people who know Emacs could hack Java, and vice-versa w/out
having to know the other language much.
>>
PK> I've suggested to Nick Sieger that he use eieio proxies for the
PK> Lisp counterparts that JUCI generates for Java classes.
>>
>> I'm very interested in doing this, and as soon as I find time to
>> learn enough about EIEIO to feel comfortable I'll do this. But for
>> now, a Java method call is mapped to a plain-old-defun :-|
Eric> [ ... ]
Eric> I can help you do this. I don't have a working JDEE install at
Eric> home though. I can help you create new classes and methods at
Eric> runtime instead of in code. The secret is that if you want to
Eric> use `defclass' or `defmethod', but don't want to write out code,
Eric> you can use `eieio-defclass' and `eieio-defmethod' instead.
Eric> Let me know what data you have and what you would ideologically
Eric> like, and I can try to prototype it for you to get you started.
Of course. Making runtime, dynamic proxies, I wouldn't have thought
of that, but it makes good sense.
On the Java side, an interface needs to be declared that we'd bind to.
There also needs to be a provided implementation of that interface to
actually invoke, but the "schema" of the object if you will should be
in a Java interface (or interface inheritance hierarchy).
The more I think about it, maybe this isn't as hard as I initially
thought. The basic idea is to create an EIEIO class for each
interface, starting with a provided interface, and traversing up the
interface's inheritance hierarchy. Does EIEIO support multiple
inheritance? Ideally it would, since Java interfaces can extend
multiple superinterfaces. A recipe for a prototype might do something
like this:
1. Call `jde-complete-get-classinfo' with the name of the Java
interface we're proxying. Currently, this returns a data structure
like the following:
(jde-complete-get-classinfo "jde.juci.test.Echo")
==>
(("ack(java.lang.String) : java.lang.String" . "ack()")
("roundTrip(java.lang.Object) : java.lang.Object" . "roundTrip()"))
where jde.juci.test.Echo looks like this:
public interface Echo {
String ack(String message);
Object roundTrip(Object input);
}
Unfortunately, `jde-complete-get-classinfo' only returns method
information, not superclass/superinterface info. Is there another
JDE method that would provide the methods of a class but also the
supers (anyone)?
2. Create the EIEIO class to be structured something like this
(assuming the implementation of the Echo interface is
`jde.juci.test.EchoImpl'):
(defclass jde-juci-test-echo ()
()
"EIEIO proxy for jde.juci.test.Echo")
(defmethod jde-juci-test-echo-ack ((this jde-juci-test-echo) message)
"Proxy method for jde.juci.test.Echo.ack(String)"
(jde-juci-invoke-java "jde.juci.test.EchoImpl" "ack" message))
(defmethod jde-juci-test-echo-round-trip ((this jde-juci-test-echo) input)
"Proxy method for jde.juci.test.Echo.ack(String)"
(jde-juci-invoke-java "jde.juci.test.EchoImpl" "ack" input))
Now, the fun part is figuring out what to do with the proxies. Does
this seem reasonable so far? Anything I left out or that you would do
differently?
The next logical step would seem to be to make JDEE plugins simple
java classes, that possibly implement a pre-defined interface. On the
Elisp side, these would be EIEIO proxies that extend a base class that
would provide the plugin infrastructure (registration in a menu,
documentation, etc.).
/Nick
Re[3]: JDEE plugins (was JUCI)
>>> Nick Sieger <[EMAIL PROTECTED]> seems to think that: >> "PK" == Paul Kinnucan <[EMAIL PROTECTED]> writes: > >PK> Eric M. Ludlam writes: >>> Something I always wanted to do was use EIEIO to wrap Java objects. >>> EIEIO could act as a proxy for Java objects, and there could be >>> Java object proxies for EIEIO objects. In this world people who >>> know Emacs could hack Java, and vice-versa w/out having to know the >>> other language much. >>> > >PK> I've suggested to Nick Sieger that he use eieio proxies for the >PK> Lisp counterparts that JUCI generates for Java classes. > >I'm very interested in doing this, and as soon as I find time to learn >enough about EIEIO to feel comfortable I'll do this. But for now, a >Java method call is mapped to a plain-old-defun :-| [ ... ] I can help you do this. I don't have a working JDEE install at home though. I can help you create new classes and methods at runtime instead of in code. The secret is that if you want to use `defclass' or `defmethod', but don't want to write out code, you can use `eieio-defclass' and `eieio-defmethod' instead. Let me know what data you have and what you would ideologically like, and I can try to prototype it for you to get you started. Eric -- Eric Ludlam: [EMAIL PROTECTED], [EMAIL PROTECTED] Home: http://www.ludlam.netSiege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org
Re[2]: JDEE plugins (was JUCI)
> "PK" == Paul Kinnucan <[EMAIL PROTECTED]> writes: PK> Eric M. Ludlam writes: >> Something I always wanted to do was use EIEIO to wrap Java objects. >> EIEIO could act as a proxy for Java objects, and there could be >> Java object proxies for EIEIO objects. In this world people who >> know Emacs could hack Java, and vice-versa w/out having to know the >> other language much. >> PK> I've suggested to Nick Sieger that he use eieio proxies for the PK> Lisp counterparts that JUCI generates for Java classes. I'm very interested in doing this, and as soon as I find time to learn enough about EIEIO to feel comfortable I'll do this. But for now, a Java method call is mapped to a plain-old-defun :-| /Nick
Re[2]: JDEE plugins (was JUCI)
Eric M. Ludlam writes: > Something I always wanted to do was use EIEIO to wrap Java objects. > EIEIO could act as a proxy for Java objects, and there could be Java > object proxies for EIEIO objects. In this world people who know > Emacs could hack Java, and vice-versa w/out having to know the other > language much. > I've suggested to Nick Sieger that he use eieio proxies for the Lisp counterparts that JUCI generates for Java classes. - Paul
Re: JDEE plugins (was JUCI)
On Wed, 19 Feb 2003, [EMAIL PROTECTED] wrote: > this plugin architecture may require enough redesign to rethink the > way JDE works now. One thing that seems prevalent in these thoughts is that the JDE is the central point of focus for this plugin architecture and the plugin architecture is hardwired to the JDE only. This obviously is understandable, because, many plugins are specific for enhancing IDEs. But there are plugins, ant, for instance, which are used outside of java IDEs. Would it make more sense to think of plugins as plugins to Emacs and the JDE as a client of the functionality newly present in Emacs? I'm worried that we are making the JDE an "everything java server" for Emacs, when shouldn't it be "just a client" to the elisp version of the everything java VM (where the VM might be the beanshell)? To say in a different way, it seems that Emacs should be enveloping a JVM, and supporting plugin architecture irrespective of the JDE. Then, the JDE should be utilizing this new elisp functionality. Then, to get new java functionality would be like going to http://anc.ed.ac.uk/~stephen/emacs/ell.html and getting a new cool elisp package to add to your Emacs experience. So what its written in java, just plug it in to Emacs and it has an elisp interface for you. Okay, I know, I'm probably smoking something, ... -- Galen deForest Boyer Sweet dreams and flying machines in pieces on the ground.
RE: JDEE plugins (was JUCI)
Hi Nick,
> Where possible, talk in terms of emacs
> interface objects (buffers, windows, frames, region, point,
> etc.) but also express them in terms of what a Java interface
> might look like. What are the logical groupings for
> retrieving certain kinds of information? What would you name
> an interface for fetching the current buffer, the current
> buffer file, the current class, etc.?
I attached the module that implements the generic Java->Emacs interface in
the jde-transmogrify package. It was done to mirror the Transmogrify Hook
interface, which I believe was derived from the JBuilder plug-in interface.
We could use it as a starting point, as it is part of a working "plug-in"
(in the sense of a Java-based add-on to JDEE).
The relevant methods (that Java code can use to change the Emacs
environment) are:
42: public void showReferencesSourced(IDefinition definition) {
57: public void showReferencesNonsourced(IDefinition definition) {
67: public void openFile(String sourceFileName)
78: public File[] getFiles()
90: public String getCurrentFile()
102: public String getUserInput(String prompt, String title)
108: public void displayMessage(String title, String message)
113: public void displayException(Exception e, String description) {
135: public String getText()
146: public String getLine(int lineNumber)
159: public void selectText(int startLineNumber,
177: public void selectText(int startPos, int endPos)
188: public void deSelectText()
198: public String getSelectedText()
208: public Enumeration getSelectedLines()
219: public int getCaretLineNumber()
230: public int getCaretOffset()
242: public int getCaretPos()
248: public int getSelectionStart()
254: public int getSelectionEnd()
266: public void setCaretPos(int lineNumber, int offset)
279: public void setCaretPos(int pos)
Regards,
Nascif
EmacsHook.java
Description: Binary data
RE: JDEE plugins (was JUCI)
> "PK" == Paul Kinnucan <[EMAIL PROTECTED]> writes: PK> Hi, You and others have raised two related but separate issues: PK> one is the need for plugin-in support and the other is a need for PK> a way to extend the JDEE that requires only Java programming PK> skills. My proposal addresses the first. I believe Nick Sieger's PK> JUCI addresses the second. Perhaps Nick could chime in and explain PK> how. So far, what I've done with JUCI allows Emacs and Java to communicate in a consistent and general way, providing a layer of abstraction above raw lisp forms printed on standard output, beanshell execution and the like. My current code in the JDEE CVS (lisp/jde-juci.el) has some very rudimentary examples (mostly unit tests), so what's there is just a shell at this point. Although it's quite easy to envision what's coming next, namely, a general interface that Java plugins could code to for receiving input and sending output, much along the lines that Nic Pottier has already started to enumerate. Let's continue to gather and take inspiration from other plugin APIs as to what sort of pieces of data need to be exchanged. Where possible, talk in terms of emacs interface objects (buffers, windows, frames, region, point, etc.) but also express them in terms of what a Java interface might look like. What are the logical groupings for retrieving certain kinds of information? What would you name an interface for fetching the current buffer, the current buffer file, the current class, etc.? >From my perspective, it'll be interesting to flesh these issues out further. Following a standard API/JSR would be ideal, but if that doesn't even exist yet, it will be hard. Also, it's going to be difficult to abstract away Emacs' tried-and-true concepts like buffers, windows, etc. The API is probably going to end up having Java objects called Buffer, Window, Frame, etc. /Nick P.S. For some technical notes on JUCI, have a look at the file java/src/jde/juci/package.html in CVS, or ask me and I'll send you a copy.
RE: JDEE plugins (was JUCI)
> "PK" == Paul Kinnucan <[EMAIL PROTECTED]> writes: [...] >> 4) Based on (3), it can replace direct invocations of the JVM with >>jde-eval >> calls (which should make it much faster) >> PK> Yes. >> Problem with (4) is how to get the output to a compilation >> buffer. When I launch a new JVM process myself, I can just redirect >> the output to any buffer I choose; if I launch the Java portion of >> the plug-in from the BeanShell, the output goes to stdout, which is >> captured as lisp forms by the BeanShell, right? Sorry if that is a >> basic elisp question, but how do I redirect that output to a >> compilation buffer? I guess I could use that code you mentioned. I >> looked at the code at jde-checkstyle.el for an example but my >> impression is that it launches an new JVM for each invocation >> instead of using the BeanShell, is that correct? As a first pass it >> should be OK for the plugin to do the same, but then we will be >> missing an opportunity for code re-use. >> Part of what you're searching for here doesn't really exist yet, at least not in a general form. As part of the discussion for what constitutes a pure Java API for allowing plugins to interact with Emacs we would want to include this specific feature (stream text to a compilation output buffer). PK> The JDEE's compile server and ant server each uses its own PK> compilation-mode buffer to display output from the BeanShell. This PK> is in addition to the comint (interactive user) buffer that is PK> used to start up the BeanShell. The reason that it is possible to PK> have multiple buffers interacting with the BeanShell is that Emacs PK> allows Lisp code to specify and change dynamically the process PK> output handler. The compile server and the ant server, after PK> sending a Java expression to the BeanShell, temporarily replace PK> the standard output handler with their own handler to handle the PK> result of evaluating the expression. My intention is to write an PK> eieio class called bsh-compilation-output-buffer that encapsulates PK> this technique. This would make it trivial for Java plugins to PK> create compilation-style buffers for handling compilation-like PK> output from Java. Critical to this technique I think will be some sort of implementation of java.io.InputStream/OutputStream or java.io.Reader/Writer on the Java side which would trigger that standard output handler switch. Could we also use a separate socket for this? Java could open a server socket and Emacs could connect to it to "download" the compilation output and stream it to a buffer. [...] >> 2) Minimal to none elisp code required. I think we will have >>elisp-based >> plug-ins as well, but I expect most to be Java-based - just because >> most JDEE users know Java much better than they know Lisp. >> >> What would be the list of "resources" available to the Java code in >> the plug-ins? Any ideas on how to make Emacs/JDEE resources like >> buffers, point position, region content, files in sourcepath, >> etc. easily available? Maybe a basic class that they could extend? >> We have to define the container environment for the plug-ins. >> PK> I'll depend on somebody else to do this. I'd be happy to take suggestions and lead up an effort to create the Java plugin API. Why don't people start listing off pieces of functionality that we can start gathering into specifications as Java interfaces. Those interfaces, after iterating on their contents could become the initial versions of that API. >> Finally, how do we manage different versions of common Java >> libraries (like XML parsers) among plug-ins? >> PK> Good question. Maven (http://jakarta.apache.org/turbine/maven/) has its plugins declare library dependencies, and even allows you to have them downloaded for you automatically! We should have a look at the Maven codebase for ideas in that area. At a minimum it would be nice to take advantage of the library repository that's been set up already (I believe it's on ibiblio.org). /Nick
RE: JDEE plugins (was JUCI)
> "MP" == Mark Pollack <[EMAIL PROTECTED]> writes: MP> Hi, Just my two cents, I'm a lisp-wimp as I am sure are many of MP> the users of JDEE, but a good Java programmer. If there was some MP> way that I could write JDEE extensions in Java for at least some MP> subset of plug-in functionality that would be great since I never MP> seem to find the time to really learn lisp. I realize it might be MP> too much to accommodate us lisp-wimps, but just keep it in mind if MP> it turns out to be not such a big deal to go in this direction. One of the things I think it would be easy to do early on is providing a command that prompts for a Java interface and will code-generate the elisp functions to match up with and be able to invoke the java interface. I think a good plugin architecture for the JDE will allow non-Elispers to get along with a minimal knowledge. There could be a fair amount of automation that, given a minimal amount of initial java code, could: 1. Generate the Elisp code. 2. Package/jar everything up according to the JDEE's plugin package structure. Also, over time, it would be nice to flesh out some standard JDEE Java APIs for prompting for user input, so there would be virtually no need at all to write custom elisp! /Nick
RE: JDEE plugins (was JUCI)
Nascif Abousalh-Neto writes: > Hi Paul, > > Just to recap: > 1) The plug-in will follow the proposed directory structure; > 2) It will have a lisp/plugin.el file that will be evaluated at load time by > JDE (still not sure what goes here, any suggestion?); plugin.el might be useful in conjunction with an autoload.el to avoid loading the entire plugin before it is used. On JDEE startup, if there is a plugin.el and an autoload.el file in the plugin's lisp directory, the JDEE itself will only load and evaluate those two files and add the plugin's lisp directory to the Emacs load-path. In this instance, plugin.el would be a bootstrap file that did the minimum things necessary to make the plugin visible, i.e., add its (autoloaded) commands to the Plugins submenu. The autoload.el file would cause Emacs itself to load any remaining Lisp files in the directory needed to support the plugin's commands. > 3) It can assume that its libraries will be in the BeanShell classpath; Yes. > 4) Based on (3), it can replace direct invocations of the JVM with jde-eval > calls (which should make it much faster) > Yes. > Problem with (4) is how to get the output to a compilation buffer. When I > launch a new JVM process myself, I can just redirect the output to any > buffer I choose; if I launch the Java portion of the plug-in from the > BeanShell, the output goes to stdout, which is captured as lisp forms by the > BeanShell, right? Sorry if that is a basic elisp question, but how do I > redirect that output to a compilation buffer? I guess I could use that code > you mentioned. I looked at the code at jde-checkstyle.el for an example but > my impression is that it launches an new JVM for each invocation instead of > using the BeanShell, is that correct? As a first pass it should be OK for > the plugin to do the same, but then we will be missing an opportunity for > code re-use. > The JDEE's compile server and ant server each uses its own compilation-mode buffer to display output from the BeanShell. This is in addition to the comint (interactive user) buffer that is used to start up the BeanShell. The reason that it is possible to have multiple buffers interacting with the BeanShell is that Emacs allows Lisp code to specify and change dynamically the process output handler. The compile server and the ant server, after sending a Java expression to the BeanShell, temporarily replace the standard output handler with their own handler to handle the result of evaluating the expression. My intention is to write an eieio class called bsh-compilation-output-buffer that encapsulates this technique. This would make it trivial for Java plugins to create compilation-style buffers for handling compilation-like output from Java. > I agree with the others that the less elisp requirements we have the larger > will be the pool of plug-in contributors; I believe JUCI will be able to > help us with this part; maybe some elisp code generation facility based on > Java Reflection or config files could also complement it. > > I think the final design goals should be: > 1) "Drop-in" install; just adding a jar or zip file to a specific directory > would be sufficient to install the package and integrate it with JDEE menus; I will support jar/zip file plugins. My plan for integrating with menus is for the plugin.el file to invoke a function called jde-plugin-menu that would specify a menu item or submenu to appear on the Plugin menu where the argument would be a standard Emacs easymenu menu specification that specifies the item's label, command, enabling/disabling conditions, format (e.g., checkbox, radiobutton), etc. > 1.1) With a plug-in manager menu to enable/disable plug-ins; Have to think about this. > 2) Minimal to none elisp code required. I think we will have elisp-based > plug-ins as well, but I expect most to be Java-based - just because most > JDEE users know Java much better than they know Lisp. > > What would be the list of "resources" available to the Java code in the > plug-ins? Any ideas on how to make Emacs/JDEE resources like buffers, point > position, region content, files in sourcepath, etc. easily available? Maybe > a basic class that they could extend? We have to define the container > environment for the plug-ins. > I'll depend on somebody else to do this. > Finally, how do we manage different versions of common Java libraries (like > XML parsers) among plug-ins? > Good question. - Paul
RE: JDEE plugins (was JUCI)
Hi, You and others have raised two related but separate issues: one is the need for plugin-in support and the other is a need for a way to extend the JDEE that requires only Java programming skills. My proposal addresses the first. I believe Nick Sieger's JUCI addresses the second. Perhaps Nick could chime in and explain how. Paul James Higginbotham writes: > > > > 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
RE: JDEE plugins (was JUCI)
Ah, thanks for the information. I actually first heard of the JSR from the JLense team, which produced a Swing equiv to the Eclipse APIs in an effort to produce a more J2SDK-friendly approach to writing rich client applications. It seems they are on the JSR in an attempt to better understand how their framework can support the JSR in the future. For now, looking at Eclipse and JBuilder APIs will probably expose the most common needs for JDE, and if the JSR succeeds, you can add the support then. Thanks for the news link, it was quite informative! James -Original Message- From: Nascif Abousalh-Neto [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 11:47 AM To: James Higginbotham; Nic Pottier; Paul Kinnucan Cc: [EMAIL PROTECTED] Subject: RE: JDEE plugins (was JUCI) Well, looks like I jumped the gun. There is not API to look at yet for this JSR 198. I suggest we just move ahead (who know long it will take to get to a point where actual APIs are defined, this looks like a very hot politic issue as well http://news.com.com/2100-1001-978445.html) and later consider a move to conform to whatever they define. In the mean time we will learn a lot :-) > -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) > > > > > > 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 >
RE: JDEE plugins (was JUCI)
Well, looks like I jumped the gun. There is not API to look at yet for this JSR 198. I suggest we just move ahead (who know long it will take to get to a point where actual APIs are defined, this looks like a very hot politic issue as well http://news.com.com/2100-1001-978445.html) and later consider a move to conform to whatever they define. In the mean time we will learn a lot :-) > -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) > > > > > > 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 >
RE: JDEE plugins (was JUCI)
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) > > > > > > 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 >
RE: JDEE plugins (was JUCI)
> 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
RE: JDEE plugins (was JUCI)
As a long time Emacs and JDE user (I think I first started using JDE in 1997) I have to throw in my 2cents and say that I'd be hugely excited with any work made towards making plugins written in Java easy to integrate with JDE. 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. :) >From the top of my head, these type of operations bound to a JDE plugin would allow >for some neat development: Input into the plugin: - class at point - object name at point - point context (what method, what class) - (user input data from minibuffer) Output from plugin: - direct output to new buffer with name.. - direct output to new buffer in split pane - insert output into current buffer at position - some way of replacing current word with output? - display menu at point? If you could bind lisp commands to a java plugin with the type of input then it might allow for a bunch of new development. I for one would spend the time to do some new things. -Nic > -Original Message- > From: Nascif Abousalh-Neto [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 19, 2003 8:35 AM > To: Paul Kinnucan > Cc: [EMAIL PROTECTED] > Subject: RE: JDEE plugins (was JUCI) > > > Hi Paul, > > Just to recap: > 1) The plug-in will follow the proposed directory structure; > 2) It will have a lisp/plugin.el file that will be evaluated > at load time by > JDE (still not sure what goes here, any suggestion?); > 3) It can assume that its libraries will be in the BeanShell > classpath; > 4) Based on (3), it can replace direct invocations of the JVM > with jde-eval > calls (which should make it much faster) > > Problem with (4) is how to get the output to a compilation > buffer. When I > launch a new JVM process myself, I can just redirect the output to any > buffer I choose; if I launch the Java portion of the plug-in from the > BeanShell, the output goes to stdout, which is captured as > lisp forms by the > BeanShell, right? Sorry if that is a basic elisp question, > but how do I > redirect that output to a compilation buffer? I guess I could > use that code > you mentioned. I looked at the code at jde-checkstyle.el for > an example but > my impression is that it launches an new JVM for each > invocation instead of > using the BeanShell, is that correct? As a first pass it > should be OK for > the plugin to do the same, but then we will be missing an > opportunity for > code re-use. > > I agree with the others that the less elisp requirements we > have the larger > will be the pool of plug-in contributors; I believe JUCI will > be able to > help us with this part; maybe some elisp code generation > facility based on > Java Reflection or config files could also complement it. > > I think the final design goals should be: > 1) "Drop-in" install; just adding a jar or zip file to a > specific directory > would be sufficient to install the package and integrate it > with JDEE menus; > 1.1) With a plug-in manager menu to enable/disable plug-ins; > 2) Minimal to none elisp code required. I think we will have > elisp-based > plug-ins as well, but I expect most to be Java-based - just > because most > JDEE users know Java much better than they know Lisp. > > What would be the list of "resources" available to the Java > code in the > plug-ins? Any ideas on how to make Emacs/JDEE resources like > buffers, point > position, region content, files in sourcepath, etc. easily > available? Maybe > a basic class that they could extend? We have to define the container > environment for the plug-ins. > > Finally, how do we manage different versions of common Java > libraries (like > XML parsers) among plug-ins? > > Regards, > Nascif
RE: JDEE plugins (was JUCI)
Hi Paul, Just to recap: 1) The plug-in will follow the proposed directory structure; 2) It will have a lisp/plugin.el file that will be evaluated at load time by JDE (still not sure what goes here, any suggestion?); 3) It can assume that its libraries will be in the BeanShell classpath; 4) Based on (3), it can replace direct invocations of the JVM with jde-eval calls (which should make it much faster) Problem with (4) is how to get the output to a compilation buffer. When I launch a new JVM process myself, I can just redirect the output to any buffer I choose; if I launch the Java portion of the plug-in from the BeanShell, the output goes to stdout, which is captured as lisp forms by the BeanShell, right? Sorry if that is a basic elisp question, but how do I redirect that output to a compilation buffer? I guess I could use that code you mentioned. I looked at the code at jde-checkstyle.el for an example but my impression is that it launches an new JVM for each invocation instead of using the BeanShell, is that correct? As a first pass it should be OK for the plugin to do the same, but then we will be missing an opportunity for code re-use. I agree with the others that the less elisp requirements we have the larger will be the pool of plug-in contributors; I believe JUCI will be able to help us with this part; maybe some elisp code generation facility based on Java Reflection or config files could also complement it. I think the final design goals should be: 1) "Drop-in" install; just adding a jar or zip file to a specific directory would be sufficient to install the package and integrate it with JDEE menus; 1.1) With a plug-in manager menu to enable/disable plug-ins; 2) Minimal to none elisp code required. I think we will have elisp-based plug-ins as well, but I expect most to be Java-based - just because most JDEE users know Java much better than they know Lisp. What would be the list of "resources" available to the Java code in the plug-ins? Any ideas on how to make Emacs/JDEE resources like buffers, point position, region content, files in sourcepath, etc. easily available? Maybe a basic class that they could extend? We have to define the container environment for the plug-ins. Finally, how do we manage different versions of common Java libraries (like XML parsers) among plug-ins? Regards, Nascif > -Original Message- > From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 18, 2003 5:25 PM > To: Abousalh-Neto, Nascif [NCRTP:3X20:EXCH] > Cc: Paul Kinnucan; [EMAIL PROTECTED] > Subject: RE: JDEE plugins (was JUCI) > > > Nascif Abousalh-Neto writes: > > Sounds like a great idea! > > > > I would volunteer to re-write the Jalopy > (http://jalopy.sourceforge.net/) > integration package I put > together. I could also take a stab at a re-write > for the > integration package for PMD (http://pmd.sourceforge.net/). > > > Those Elisp->Java packages have an awful lot of code in > common, and it would > be really nice to create a standard > way to create them - specially the bit > about a standard > way to integrate with the BeanShell. > > > Great. I assume that you will conform to the directory > structure that I proposed and provide the package as a jar or > lisp file. Please let me know if you intend to implement any > other suggestions, e.g., Ole's idea of a standard entry > point: lisp/plugin.el > > > I would like to suggest also a standard way for those > packages to present > their output. A lot of them generate > warnings or errors that go very well in > a "compilation" > mode buffer. I think this behavior can be abstracted as > well. > > > beanshell.el previously contained an unfinished eieio class > that provides a compilation-style buffer for BeanShell-based > applications. My idea is that the compile server and the ant > package and any other Beanshell based applications that > needed compilation-like buffers could specialize and > instantiate this class. I deleted it in my last update but I > think I'll revive it. > > - Paul > > > Regards, > > Nascif > > > > > > > > > -Original Message- > > > From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, February 18, 2003 3:27 PM > > > To: [EMAIL PROTECTED] > > > Subject: JDEE plugins (was JUCI) > > > > > > > > > > > > Hi Nick, > > > > > > I am posting my response to your idea of JUCI-based > plugins > > to the JDEE list because I am interested > > > in getting other people's input on this idea. > > > > > - Paul > > > > > > >
RE: JDEE plugins (was JUCI)
I second those sentiments and that motion. / Petter > -Original Message- > From: Mark Pollack [mailto:[EMAIL PROTECTED]] > Sent: den 19 februari 2003 02:01 > To: Paul Kinnucan; Nascif Abousalh-Neto > Cc: [EMAIL PROTECTED] > Subject: RE: JDEE plugins (was JUCI) > > > Hi, > > Just my two cents, I'm a lisp-wimp as I am sure are many of > the users of > JDEE, but a good Java programmer. If there was some way that I could > write JDEE extensions in Java for at least some subset of plug-in > functionality that would be great since I never seem to find > the time to > really learn lisp. I realize it might be too much to accommodate us > lisp-wimps, but just keep it in mind if it turns out to be not such a > big deal to go in this direction. > > Cheers, > Mark > > > > -Original Message- > From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 18, 2003 5:25 PM > To: Nascif Abousalh-Neto > Cc: Paul Kinnucan; [EMAIL PROTECTED] > Subject: RE: JDEE plugins (was JUCI) > > > Nascif Abousalh-Neto writes: > > Sounds like a great idea! > > > > I would volunteer to re-write the Jalopy > (http://jalopy.sourceforge.net/) > integration package I put > together. > I could also take a stab at a re-write > for the integration package > for PMD (http://pmd.sourceforge.net/). > > > Those Elisp->Java packages have an awful lot of code in common, and > it would > be really nice to create a standard way to create them - > specially the bit > about a standard way to integrate with the > BeanShell. > > > Great. I assume that you will conform to the directory > structure that I > proposed and provide the package as a jar or lisp file. Please let me > know if you intend to implement any other suggestions, e.g., > Ole's idea > of a standard entry point: lisp/plugin.el > > > I would like to suggest also a standard way for those packages to > present > their output. A lot of them generate warnings or > errors that > go very well in > a "compilation" mode buffer. I think this behavior > can be abstracted as > well. > > > beanshell.el previously contained an unfinished eieio class that > provides a compilation-style buffer for BeanShell-based > applications. My > idea is that the compile server and the ant package and any other > Beanshell based applications that needed compilation-like > buffers could > specialize and instantiate this class. I deleted it in my last update > but I think I'll revive it. > > - Paul > > > Regards, > > Nascif > > > > > > > > > -Original Message- > > > From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, February 18, 2003 3:27 PM > > > To: [EMAIL PROTECTED] > > > Subject: JDEE plugins (was JUCI) > > > > > > > > > > > > Hi Nick, > > > > > > I am posting my response to your idea of JUCI-based plugins > > > to the JDEE list because I am interested > > in getting > other people's > input on this idea. > > > > > - Paul > > > > > > > > > Nick Sieger writes: > > > > > > [snip] > > > > > > > Do you have a long-term vision for any standard interface > > > or API for > integrating user-developed components? Right > > > now, most of the > user-submitted code seems to be little > > > snippets here and there. It > would be cool if people could > > > share pieces of code in a manner that > they could just drop > > > a file or a jar archive in a well-known place in > the JDEE > > > installation filesystem and the JDEE would auto-detect the > > > > new component, load it up and make the code available. > > > > > > > I haven't really thought about it. One thing that occurs to > > > me is that I could add a subdirectory called plugins to the > > > JDEE tree where users could put an entire hybrid Java/Lisp > > > plugin, i.e., the JDEE tree would look like this: > > > > > > JDEEroot > > > lisp > > > java > > > doc > > > plugins > > > plugin1 > > > lisp > > > java > > > scripts > > > classes > > > src > > > lib > > > doc > > > javadoc > > > design > > > help > > >
Re: JDEE plugins (was JUCI)
> "Paul" == Paul Kinnucan <[EMAIL PROTECTED]> writes: Paul> Hi Nick, Paul> I am posting my response to your idea of JUCI-based plugins Paul> to the JDEE list because I am interested in getting other Paul> people's Paul> input on this idea. This sounds like a thoroughly good idea to me. I've contributed lisp to JDE in the past, which is very easy to do, but I've never added Java, because I never got the build working on a unix box. I was looking at jrefactory the other day, and thought that would be nice to integrate in, but it needs some Java code in the way. And then the whole thing needs to be made available to JDE, so that it can be run from bsh. A simple plugin architecture would make this all easier. So, yeah, sounds sensible to me. Phil
RE: JDEE plugins (was JUCI)
Hi, Just my two cents, I'm a lisp-wimp as I am sure are many of the users of JDEE, but a good Java programmer. If there was some way that I could write JDEE extensions in Java for at least some subset of plug-in functionality that would be great since I never seem to find the time to really learn lisp. I realize it might be too much to accommodate us lisp-wimps, but just keep it in mind if it turns out to be not such a big deal to go in this direction. Cheers, Mark -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 5:25 PM To: Nascif Abousalh-Neto Cc: Paul Kinnucan; [EMAIL PROTECTED] Subject: RE: JDEE plugins (was JUCI) Nascif Abousalh-Neto writes: > Sounds like a great idea! > > I would volunteer to re-write the Jalopy (http://jalopy.sourceforge.net/) > integration package I put together. I could also take a stab at a re-write > for the integration package for PMD (http://pmd.sourceforge.net/). > > Those Elisp->Java packages have an awful lot of code in common, and it would > be really nice to create a standard way to create them - specially the bit > about a standard way to integrate with the BeanShell. > Great. I assume that you will conform to the directory structure that I proposed and provide the package as a jar or lisp file. Please let me know if you intend to implement any other suggestions, e.g., Ole's idea of a standard entry point: lisp/plugin.el > I would like to suggest also a standard way for those packages to present > their output. A lot of them generate warnings or errors that go very well in > a "compilation" mode buffer. I think this behavior can be abstracted as > well. > beanshell.el previously contained an unfinished eieio class that provides a compilation-style buffer for BeanShell-based applications. My idea is that the compile server and the ant package and any other Beanshell based applications that needed compilation-like buffers could specialize and instantiate this class. I deleted it in my last update but I think I'll revive it. - Paul > Regards, > Nascif > > > > > -Original Message- > > From: Paul Kinnucan [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, February 18, 2003 3:27 PM > > To: [EMAIL PROTECTED] > > Subject: JDEE plugins (was JUCI) > > > > > > > > Hi Nick, > > > > I am posting my response to your idea of JUCI-based plugins > > to the JDEE list because I am interested > > in getting other people's input on this idea. > > > > - Paul > > > > > > Nick Sieger writes: > > > > [snip] > > > > > Do you have a long-term vision for any standard interface > > or API for > integrating user-developed components? Right > > now, most of the > user-submitted code seems to be little > > snippets here and there. It > would be cool if people could > > share pieces of code in a manner that > they could just drop > > a file or a jar archive in a well-known place in > the JDEE > > installation filesystem and the JDEE would auto-detect the > > > new component, load it up and make the code available. > > > > > I haven't really thought about it. One thing that occurs to > > me is that I could add a subdirectory called plugins to the > > JDEE tree where users could put an entire hybrid Java/Lisp > > plugin, i.e., the JDEE tree would look like this: > > > > JDEEroot > > lisp > > java > > doc > > plugins > > plugin1 > > lisp > > java > >scripts > >classes > > src > > lib > > doc > > javadoc > > design > > help > > info > > html > > src > > plugin2 > > ... > > > > The JDEE would load/eval the files in the lisp directory > > and add the classes directory and the jar files in the > > lib directory to the BeanShell's classpath. I could also > > add a Plugins submenu to the JDEE menu and define a JDEE > > Lisp function that plugins could call to > > add a command or submenu of commands to the Plugins directory. > > > > This solution is not as convenient as your idea of a single > > jar file. But remember that one of the principles of freeware > > is to include the source. Perhaps the first time the JDEE > > detects a jar or zip file at the top level of the Plugins > > directory it could unpack it, assuming that its contents are >
Re: JDEE plugins (was JUCI)
On Tue, 18 Feb 2003, [EMAIL PROTECTED] wrote: > Sounds like a great idea! > > I would volunteer to re-write the Jalopy > (http://jalopy.sourceforge.net/) integration package I put > together. I could also take a stab at a re-write for the > integration package for PMD (http://pmd.sourceforge.net/). > > Those Elisp->Java packages have an awful lot of code in common, > and it would be really nice to create a standard way to create > them - specially the bit about a standard way to integrate with > the BeanShell. > > I would like to suggest also a standard way for those packages > to present their output. A lot of them generate warnings or > errors that go very well in a "compilation" mode buffer. I > think this behavior can be abstracted as well. Maybe the beanshell could be viewed as an application server. Let me work through my thoughts. Would it make sense that java code that is executed through the beanshell not have to "println(someElispString);" but instead, any java code that is to be executed by the beanshell and subsequently eval'd into elisp, return a "java datatypes transformable to elisp" set of objects, like hashmap, array, ... Then, the beanshell could offer a set of classes which take these particular return objects and transform them into println's of elisp strings to be eval'd by elisp. The only part that doesn't seem clear to me is how to have elisp not have to understand the java code, its structure and exact names as well as its exact syntax. I'm thinking, first an eieio interface to elisp be required to be implemented by the elisp code of the package. A mapping layer, maybe xml, or just elisp list, be used to wire elisp class/method names to java class/methods. Then, the elisp package integrates with a particular elisp interface and the java code integrates with a particular java interface and the elisp to java is the black box that none of the two sides of code knows about, taken care of by the beanshell's black box. This would also allow java requirements for some particular need of the JDEE to be given to a willing java coder and the elisp requirements given to a willing elisp coder and the two sides actually code in their respective VMs without having to hook the two, fairly incompatible VMs up during development. Of course, what I'm thinking is that a JDE user could integrate some jakarta package by working with Paul on the java interface needing to be implemented. Paul or another of the elisp studs, then codes up the elisp side of the house waiting for the java coder to finish his work. Then, elisp becomes a client and the java code becomes the middleware implementing interfaces the beanshell application server will be executing. -- Galen Boyer
