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 > > > 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>> &nb > sp; > javadoc</FONT> > <BR><FONT > SIZE=2>> &nb > sp; > 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. >
