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 > > > > > > > > > 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 > > > > > > > > >
