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
