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 > > 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 or that are available only inside of an > > organization (e.g., a plugin to supports particular > > development organizations built-and-test system. > > > > - Paul > > > > > > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> > <HTML> > <HEAD> > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"> > <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89"> > <TITLE>RE: JDEE plugins (was JUCI)</TITLE> > </HEAD> > <BODY> > > <P><FONT SIZE=2>Sounds like a great idea!</FONT> > </P> > > <P><FONT SIZE=2>I would volunteer to re-write the Jalopy (<A HREF="http://jalopy.sourceforge.net/"; TARGET="_blank">http://jalopy.sourceforge.net/</A>) integration package I put together. I could also take a stab at a re-write for the integration package for PMD (<A HREF="http://pmd.sourceforge.net/"; TARGET="_blank">http://pmd.sourceforge.net/</A>).</FONT></P> > > <P><FONT SIZE=2>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.</FONT></P> > > <P><FONT SIZE=2>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.</FONT></P> > > <P><FONT SIZE=2>Regards,</FONT> > <BR><FONT SIZE=2> Nascif</FONT> > </P> > <BR> > <BR> > > <P><FONT SIZE=2>> -----Original Message-----</FONT> > <BR><FONT SIZE=2>> From: Paul Kinnucan [<A HREF="mailto:[EMAIL PROTECTED]";>mailto:[EMAIL PROTECTED]</A>] </FONT> > <BR><FONT SIZE=2>> Sent: Tuesday, February 18, 2003 3:27 PM</FONT> > <BR><FONT SIZE=2>> To: [EMAIL PROTECTED]</FONT> > <BR><FONT SIZE=2>> Subject: JDEE plugins (was JUCI)</FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> Hi Nick,</FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> I am posting my response to your idea of JUCI-based plugins</FONT> > <BR><FONT SIZE=2>> to the JDEE list because I am interested</FONT> > <BR><FONT SIZE=2>> in getting other people's input on this idea.</FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> - Paul</FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> Nick Sieger writes:</FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> [snip]</FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> > Do you have a long-term vision for any standard interface </FONT> > <BR><FONT SIZE=2>> or API for > integrating user-developed components? Right </FONT> > <BR><FONT SIZE=2>> now, most of the > user-submitted code seems to be little </FONT> > <BR><FONT SIZE=2>> snippets here and there. It > would be cool if people could </FONT> > <BR><FONT SIZE=2>> share pieces of code in a manner that > they could just drop </FONT> > <BR><FONT SIZE=2>> a file or a jar archive in a well-known place in > the JDEE </FONT> > <BR><FONT SIZE=2>> installation filesystem and the JDEE would auto-detect the > </FONT> > <BR><FONT SIZE=2>> new component, load it up and make the code available. > </FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> I haven't really thought about it. One thing that occurs to </FONT> > <BR><FONT SIZE=2>> me is that I could add a subdirectory called plugins to the </FONT> > <BR><FONT SIZE=2>> JDEE tree where users could put an entire hybrid Java/Lisp </FONT> > <BR><FONT SIZE=2>> plugin, i.e., the JDEE tree would look like this:</FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> JDEEroot</FONT> > <BR><FONT SIZE=2>> lisp</FONT> > <BR><FONT SIZE=2>> java</FONT> > <BR><FONT SIZE=2>> doc</FONT> > <BR><FONT SIZE=2>> plugins</FONT> > <BR><FONT SIZE=2>> plugin1</FONT> > <BR><FONT SIZE=2>> lisp</FONT> > <BR><FONT SIZE=2>> java</FONT> > <BR><FONT SIZE=2>> scripts</FONT> > <BR><FONT SIZE=2>> classes</FONT> > <BR><FONT SIZE=2>> src</FONT> > <BR><FONT SIZE=2>> lib</FONT> > <BR><FONT SIZE=2>> doc</FONT> > <BR><FONT SIZE=2>> javadoc</FONT> > <BR><FONT SIZE=2>> design</FONT> > <BR><FONT SIZE=2>> help</FONT> > <BR><FONT SIZE=2>> info</FONT> > <BR><FONT SIZE=2>> html</FONT> > <BR><FONT SIZE=2>> src</FONT> > <BR><FONT SIZE=2>> plugin2</FONT> > <BR><FONT SIZE=2>> ...</FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> The JDEE would load/eval the files in the lisp directory</FONT> > <BR><FONT SIZE=2>> and add the classes directory and the jar files in the </FONT> > <BR><FONT SIZE=2>> lib directory to the BeanShell's classpath. I could also</FONT> > <BR><FONT SIZE=2>> add a Plugins submenu to the JDEE menu and define a JDEE </FONT> > <BR><FONT SIZE=2>> Lisp function that plugins could call to</FONT> > <BR><FONT SIZE=2>> add a command or submenu of commands to the Plugins directory.</FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> This solution is not as convenient as your idea of a single </FONT> > <BR><FONT SIZE=2>> jar file. But remember that one of the principles of freeware </FONT> > <BR><FONT SIZE=2>> is to include the source. Perhaps the first time the JDEE </FONT> > <BR><FONT SIZE=2>> detects a jar or zip file at the top level of the Plugins </FONT> > <BR><FONT SIZE=2>> directory it could unpack it, assuming that its contents are </FONT> > <BR><FONT SIZE=2>> structured as I proposed. This would provide the ease of </FONT> > <BR><FONT SIZE=2>> distribution and installation that you have in mind with my </FONT> > <BR><FONT SIZE=2>> objective of ensuring that plugins are complete packages with </FONT> > <BR><FONT SIZE=2>> Lisp, Java, design and API doc, and user doc (i.e., html </FONT> > <BR><FONT SIZE=2>> and/or info help files).</FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> How does this sound to you? </FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> I won't do this until somebody actually writes a genuinely </FONT> > <BR><FONT SIZE=2>> useful plugin that I could use to test the plugin support code.</FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> Or perhaps someone could undertake to restructure one of</FONT> > <BR><FONT SIZE=2>> the existing JDEE packages as a plugin, e.g., checkstyle.</FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> We could have standard plugins that would ship with the</FONT> > <BR><FONT SIZE=2>> JDEE distribution (e.g., checkstyle) and plugins available </FONT> > <BR><FONT SIZE=2>> independently or that are available only inside of an </FONT> > <BR><FONT SIZE=2>> organization (e.g., a plugin to supports particular </FONT> > <BR><FONT SIZE=2>> development organizations built-and-test system.</FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> - Paul</FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> </FONT> > <BR><FONT SIZE=2>> </FONT> > </P> > > </BODY> > </HTML> ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com Get closer to the financial markets with Reuters Messaging - for more information and to register, visit http://www.reuters.com/messaging Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.
