For Alan's goal to create an ABCL plugin for Protege–which is an Eclipse RCP application so this work contributes to running ABCL on Eclipse Equinox and OSGi in general–I've gotten to a fairly stable state for which I've creating the attached patches from my local snapshots.
That's "patches" because I ended up creating an Eclipse OSGi project for ABCL itself separate from the org.sciencecommons.protege.lisp so I could run Protege under Eclipse to interactively debug things.
With [r12696][1], the ABCL trunk contains the necessary support in Pathnames to run as an Eclipse OSGi bundle. I have backported these changes to the abcl-0.20 branch, so as long as nothing else crops up, this release should be a good starting point.
[1]: http://trac.common-lisp.net/armedbear/changeset/12696
Since I needed to debug ABCL's load procedure in Eclipse, instead of using Alan's procedure I [followed the instructions for building Protege from Eclipse][2], and then added the abcl and org.sciencecommons.protege.lisp plugins. Therefore, the patches in this email "convert" abcl and org.sciencecommons.protege.lisp to Eclipse OSGi projects. It should be possible to build purely from Ant as Alan described with the additional step of invoking Ant on the 'abcl/protege-build.xml' with the PROTEGE_HOME set to the proper value.
[2]: http://protegewiki.stanford.edu/wiki/CompileProtege4InEclipseFromSvn
To build and run Protege with the Lisp plugin from Eclipse:
1. Follow the instructions to [building Protege from Eclipe][2]
2. Checkout the abcl SVN trunk (later than r12696) into the workspace.
3. Apply 'abcl-osgi.patch' to the abcl directory
4. Apply 'org.sciencecommons.protege.lisp.patch' to the corresponding directory.
5. Create the external tool builder configurations to build abcl and org.sciencecommons.protege.lisp by following the instructions [to "add your own plugin"][3]. For abcl, you will be adding "protege-build.xml".
6. Build abcl and then org.sciencecommons.protege.lisp form the external tool build configuration created in step 5
7. Run Protege by using the "Protege.From.Build" run configuration.
[3]: http://protegewiki.stanford.edu/wiki/CompileProtege4InEclipseFromSvn#Add_you...
Some improvements over the previous state:
1. ABCL loads fully, including SWANK via ASDF
2. The J editor no longer appears.
Some problems:
1. The REPL thread is being started in the GUI constructor at the moment. The general OSGi contract is that a bundle must only start threads with the Activator.start() method, and all threads must be stopped when Activator.stop() returns.
2. I'd actually like to have the abcl container start()/stop() relevant OSGi threads so that the bundling is useful for other containers. To this end, I am imagining a simple message server for ABCL that takes messages as they come in, and ships them off to REPL threads as necessary, returning the results. There would be an optional argument to such messages that would specify a thread to execute on. Under this proposal, other OSGi bundles would only be able to "communicate" with EVAL. Is this too restrictive? It probably is if only Strings are going back and forth, but maybe if we allowed LispObjects that were somehow "deep copied" back and forth, providing access to the useful routines.
3. There are parts of ABCL that call System.exit() (at least one is present in Autoload.load()), which is not going to work well. I plan to replace this somehow, perhaps by waiting for all tasks to finish, then signaling that the singleton Interpreter is no longer valid by disposing of the reference?
4. I think it would be useful to move the JPanel code into base ABCL for a basic interactive REPL. This would facilitate embedding ABCL in many tools where the core functionality is maintained in central location. This would allow Netbeans, for example, to easily include a GUI to the ABCL REPL. I would not favor this being a full IDE effort at all, but would provide the base GUI element that others could customize. At the same time, maybe we should consider removing unused parts of the org.armedbear.lisp.java.{awt,swing}.* classes? Is this something used by J that could profitably moved over?
5. 'build.xml' needs to be OSGi build-aware in a better manner. The current patchset assumes that the user will always be doing an OSGi build when it is invoked.
Comments, feedback, et. al. solicited, Mark