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)
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 interestedin 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 structured as I proposed. This would provide the ease of distribution and installation that you have in mind with my objective of ensuring that plugins are complete packages with Lisp, Java, design and API doc, and user doc (i.e., html and/or info help files). How does
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)
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
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) 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
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) 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
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) 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
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: 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
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)
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)
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)
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)
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)
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, 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 interestedin 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 structured as I proposed. This would provide the ease of distribution and installation that you have in mind with my objective of ensuring that plugins are complete packages with Lisp, Java, design and API doc, and user doc (i.e., html and/or info help files). How does this sound to you? I won't do this until somebody actually writes a genuinely useful plugin that I could use to test the plugin support code. Or perhaps someone could undertake to restructure one of the existing JDEE packages as a plugin, e.g., checkstyle. We could have standard plugins that would ship with the JDEE distribution (e.g., checkstyle) and plugins available independently
