Here's a quick attempt - let me know if it doesn't compile for some reason. Running now but wanted to give you something: svn co http://smi-protege.stanford.edu/repos/protege/protege4/protege-base/trunk svn co http://smi-protege.stanford.edu/repos/protege/protege4/plugins/org.protege.c... svn co http://smi-protege.stanford.edu/repos/protege/protege4/plugins/org.protege.e... svn co http://smi-protege.stanford.edu/repos/protege/protege4/plugins/org.semanticw... svn co http://smi-protege.stanford.edu/repos/protege/protege4/plugins/org.protege.e... svn co http://svn.neurocommons.org/svn/trunk/protege/org.sciencecommons.protege.lis... svn co http://smi-protege.stanford.edu/repos/protege/protege4/plugins/binary mkdir Protege41.app build script: #!/bin/tcsh setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/ setenv PROTEGE_HOME `pwd`/Protege41.app echo building protege-base (cd protege-base; ant osx) foreach dir (org.protege.common org.protege.editor.core.application org.semanticweb.owl.owlapi org.protege.editor.owl org.sciencecommons.protege.lisp) echo building $dir (cd $dir; ant install) end cp binary/org.semanticweb.HermiT.jar Protege41.app/Contents/Resources/Java/plugins/ -Alan On Fri, Apr 16, 2010 at 2:05 AM, Mark Evenson <evenson@panix.com> wrote:

On 4/16/10 12:41 AM, Alan Ruttenberg wrote:

...

Alessio found some threading issues with his console, and with those fixed I am able to use it within protege and it no longer hangs after one or two commands. (Thanks!)

Using the latest abcl, there also seems to be some bundle: url goodness happening. I no longer see the unbound variable issue, and I see bundle: uris for abcl-defined lisp code being loaded - snap attached - I recorded a screen movie and grabbed the last it showed before crashing.

Could you place a network accessible snapshot of your progress so I could reproduce it and help out with the OSGi issues?

I'm glad that 'bundle:' URLs sort of load, but it would be miraculous if there weren't any bugs whatsoever in the URL pathname code I just committed. Looking at the logs you provided seems to show a fair number of failed 'bundle:' loads before the JCLASS-FIELDS error, but maybe they are defaulting to a different location that is succeeding.  It's hard for me to tell.

-- "A screaming comes across the sky.  It has happened before, but there is nothing to compare to it now."

_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

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 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

On 5/19/10 9:42 AM, Alessio Stalla wrote: […]

I'm afraid that disposing the Interpreter and starting a new one is not the same as rebooting ABCL. Most of the state is reachable from static fields; the list of packages is static, for example. That said, System.exit() should really be removed in favor of an Interpreter.quit() or something like that, which will call System.exit() in the default case, but may be overridden in order to do other things in certain environments. If you want to have multiple instances of ABCL running in parallel, or even simply to restart it without restarting the JVM, you have to run each instance in a dedicated classloader. If, as I have understood, you intend to use ABCL as a service provider accessed through some kind of "remoting" layer (even when on the same machine as the other modules), then it's perfectly fine to have ABCL locked in its own private world, since all communication with it will be through message passing - *if* the type of those messages is a class which is shared among all the ABCL instances, i.e. loaded by a shared parent classloader, i.e. not LispObject. I'm talking of the actual Class of the message here - a byte[] containing a serialized LispObject would be fine.

How does one (de)serialize a LispObject to byte[]? We don't implement the java.io.Serializable contract so as far as I can tell, we need a fair amount of implementation work here. Or have I missed something simple? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

Sorry I'm behind on this. In what sense is ABCL "isolated"? For example, in the context of protege, the whole point is to be able to interact with the same objects the protege editor is interactive with. -Alan On Wed, May 19, 2010 at 8:01 AM, Mark Evenson <evenson@panix.com> wrote:

On 5/19/10 9:42 AM, Alessio Stalla wrote:

[…]

...

I'm afraid that disposing the Interpreter and starting a new one is not the same as rebooting ABCL. Most of the state is reachable from static fields; the list of packages is static, for example. That said, System.exit() should really be removed in favor of an Interpreter.quit() or something like that, which will call System.exit() in the default case, but may be overridden in order to do other things in certain environments. If you want to have multiple instances of ABCL running in parallel, or even simply to restart it without restarting the JVM, you have to run each instance in a dedicated classloader. If, as I have understood, you intend to use ABCL as a service provider accessed through some kind of "remoting" layer (even when on the same machine as the other modules), then it's perfectly fine to have ABCL locked in its own private world, since all communication with it will be through message passing - *if* the type of those messages is a class which is shared among all the ABCL instances, i.e. loaded by a shared parent classloader, i.e. not LispObject. I'm talking of the actual Class of the message here - a byte[] containing a serialized LispObject would be fine.

How does one (de)serialize a LispObject to byte[]?  We don't implement the java.io.Serializable contract so as far as I can tell, we need a fair amount of implementation work here.  Or have I missed something simple?

--

"A screaming comes across the sky.  It has happened before, but there is nothing to compare to it now."

_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

On Wed, May 19, 2010 at 11:35 AM, Alessio Stalla <alessiostalla@gmail.com> wrote:

On Wed, May 19, 2010 at 5:21 PM, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:

...

Sorry I'm behind on this. In what sense is ABCL "isolated"? For example, in the context of protege, the whole point is to be able to interact with the same objects the protege editor is interactive with.

That's a matter of correctly configuring the classloaders. I don't know if OSGi puts any restriction here, but in general if you make sure the ABCL "private" classloader has the Protege one as one its ancestors, then ABCL will be able to access all the classes known to Protege. If you want to pass live Protege objects to the private ABCL world, you'll have to construct some machinery to expose some parts of ABCL through a common interface, and get a reference to an instance of that interface using reflection.

Of course, the whole point of all this is to be able to run multiple ABCL instances. If you don't have this need, going through all this pain is useless.

AFAIK, I only need one. -Alan

Alessio

On Wed, May 19, 2010 at 2:45 PM, Mark Evenson <evenson@panix.com> wrote:

On 5/19/10 9:42 AM, Alessio Stalla wrote:

[…]

...

...

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?

What is the JPanel code? As part of my "Snow" GUI library, I have a basic REPL, debugger and inspector available. The REPL is pure Java and does not depend on anything but Swing/AWT, so it could be included in ABCL as-is. There's room for improvement, but it's already usable as it is if you don't expect fancy things from it. The Lisp interface to the REPL, the debugger and the inspector instead are written in Lisp and depend on the Snow DSL. I know Alan successfully ran the Snow REPL with Protege (after some bugfixing).

The org.sciencecommons.protege.lisp plugin uses snow.swing.ConsoleDocument, so I would propose we move a version of this to org.armedbear.lisp.java.swing.Console more or less as-is.  Any thoughts on how you want to maintain the dependence between this and the rest of Snow?

If the REPL is part of ABCL, Snow will just use it :) i.e. all I need to change is a package name. However, there's a little catch. Currently the REPL in ABCL is not supposed to run multiple times concurrently, because it relies on some global state. The visible part of it is the incrementing counter shown at the prompt, but I can't exclude that there's some more important state which should not be shared. In Snow I solved this running exclusively either the console REPL or the GUI one, but in ABCL probably it would make more sense to bind all the REPL state in a thread-local manner, if possible, to allow multiple REPLs to run happily together. That, and we will need a way to tell Main which REPL to launch.

For the rest of the classes under org.armedbear.lisp.java I would propose perhaps moving them to the examples hierarchy?  It does not seem that J depends on them.  Neither does Snow from what I could grep. Does anybody know of any consumers of these interfaces?  And does it seem like a good idea to move them to the examples hierarchy?  If we agree to such a move, I would agree to produce some amount of documentation for the use in examples.

org.armedbear.lisp.java.DialogPromptStream and its two subclasses, one in .awt and one in .swing, are stuff from Snow too. I didn't remember them to be ported to ABCL, and I doubt anyone is using them. The other classes seem to be related to J. I second your proposal of moving everything to the examples. Regards, Alessio

Hi Mark! Thanks a lot! I've been playing and notice a couple of things. 1) Added jscheme.jar as my jss code uses that 2) Fixed a couple of jss bootstrappy things to make it happy 3) Does load bind the readtable? I can't seem to side-effect it when loading jss and so have to type (set-dispatch-macro-character #\# #\" 'read-invoke) to get it to take effect 4) Having some kind of classpath issues still. When I try (show-classtree " http://purl.obolibrary.org/obo/iao.owl") (after loading my ow2 package sucessfully), which should exercise a bunch of stuff, I get a class not found error in the OWLAPI code. owlxmlparser/src/main/java/org/coode/owlapi/owlxmlparser/OWLXMLParserFactory.java "java.lang.NoClassDefFoundError: javax/xml/parsers/ParserConfigurationException at org.coode.owlapi.owlxmlparser.OWLXMLParserFactory.createParser(OWLXMLParserFactory.java:39) at uk.ac.manchester.cs.owl.owlapi.ParsableOWLOntologyFactory.getParsers(ParsableOWLOntologyFactory.java:82) at uk.ac.manchester.cs.owl.owlapi.ParsableOWLOntologyFactory.loadOWLOntology(ParsableOWLOntologyFactory.java:158) at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:633) at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntologyFromOntologyDocument(OWLOntologyManagerImpl.java:591) " This is code that uses jss for the jar management and I have no idea how this interacts with the classpath management of OSGI. I guess OSGI is doing various kinds of isolation and I want to blow all the isolation away :) I guess I'm bound to lose somehow - I'm dynamically loading the OWLAPI jar, for instance, but protege has it loaded? I guess I can skip loading them with jss if I can figure out how to use the ones that protege has loaded. They are in various plugins. Right now the jss code looks at the classpath to figure out what jars it should parse to get class names. I suppose by analogy I would look through the bundles for classnames. Is there a way to programmatically determine which bundles are available? To add them programmatically? Or do I need to recompile the plugin to get access to a new plugin? e.g. I see that I can get a protege editor class: (jclass "org.protege.editor.core.FileUtils") -> #<java class org.protege.editor.core.FileUtils {39C7}> But jss doesn't know about it: (find-java-class 'core.fileutils) -> NIL #<ERROR {5D08B1}> If you have a pointer to your favorite doc about how the OSGI classloading works, please let me know. -Alan On Thu, May 20, 2010 at 3:01 PM, Mark Evenson <evenson@panix.com> wrote:

Alan granted me commit rights, so I have updated the org.sciencecommons.lisp.protege plugin to a (hopefully) fully working version. Instead of breaking ABCL out in a separate OSGi bundle, I included it in the org.sciecommons.lisp.protege bundle directly as a) I'd like to get ABCL out to the Protege community for use who probably couldn't care less as long as they have a Common Lisp plugin, and b) working through the threading/isolation issues doesn't look like a quick task.

Attached to this mail is a tentative README cobbled together from Alan's initial emails.

-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

On Fri, May 21, 2010 at 8:38 AM, Alessio Stalla <alessiostalla@gmail.com>wrote:

On Fri, May 21, 2010 at 1:26 PM, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:

...

4) Having some kind of classpath issues still. When I try (show-classtree "http://purl.obolibrary.org/obo/iao.owl") (after loading my ow2 package sucessfully), which should exercise a bunch of stuff, I get a class not found error in the OWLAPI code.

owlxmlparser/src/main/java/org/coode/owlapi/owlxmlparser/OWLXMLParserFactory.java

...

"java.lang.NoClassDefFoundError: javax/xml/parsers/ParserConfigurationException at

org.coode.owlapi.owlxmlparser.OWLXMLParserFactory.createParser(OWLXMLParserFactory.java:39)

...

at

uk.ac.manchester.cs.owl.owlapi.ParsableOWLOntologyFactory.getParsers(ParsableOWLOntologyFactory.java:82)

...

at

uk.ac.manchester.cs.owl.owlapi.ParsableOWLOntologyFactory.loadOWLOntology(ParsableOWLOntologyFactory.java:158)

...

at

uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:633)

...

at

...

" This is code that uses jss for the jar management and I have no idea how this interacts with the classpath management of OSGI. I guess OSGI is doing various kinds of isolation and I want to blow all the isolation away :) I guess I'm bound to lose somehow - I'm dynamically loading the OWLAPI jar, for instance, but protege has it loaded? I guess I can skip loading them with jss if I can figure out how to use the ones that protege has loaded. They are in various plugins. Right now the jss code looks at the classpath to figure out what jars it should parse to get class names. I suppose by analogy I would look

uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntologyFromOntologyDocument(OWLOntologyManagerImpl.java:591) through

...

the bundles for classnames. Is there a way to programmatically determine which bundles are available? To add them programmatically? Or do I need to recompile the plugin to get access to a new plugin? e.g. I see that I can get a protege editor class: (jclass "org.protege.editor.core.FileUtils") -> #<java class org.protege.editor.core.FileUtils {39C7}> But jss doesn't know about it: (find-java-class 'core.fileutils) -> NIL #<ERROR {5D08B1}> If you have a pointer to your favorite doc about how the OSGI classloading works, please let me know.

Do you have control on the classloader used by jss? If jclass works, it means that the classloader that loaded org.armedbear.lisp.Lisp knows about FileUtils. If you can force the jss classloader to use Lisp.class.getClassLoader() as its parent, it should work, too.

I do, but currently it depends on being able to dynamically load jars. I'd like to retain this capability. It uses bsh.ClassManager but it might do to work with bsh.classpath.BshClassLoader. There's also my dwimming of classnames that depends on being able to get a list of classes to index. -Alan

hth, Alessio

On Fri, May 21, 2010 at 9:44 AM, Alessio Stalla <alessiostalla@gmail.com>wrote:

On Fri, May 21, 2010 at 3:23 PM, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:

...

...

Do you have control on the classloader used by jss? If jclass works, it means that the classloader that loaded org.armedbear.lisp.Lisp knows about FileUtils. If you can force the jss classloader to use Lisp.class.getClassLoader() as its parent, it should work, too.

I do, but currently it depends on being able to dynamically load jars. I'd like to retain this capability. It uses bsh.ClassManager but it might do to work with bsh.classpath.BshClassLoader.

I didn't mean that you should lose that ability. If you have the chance to decide which parent classloader bsh.ClassManager gets to use, you can pass to it the classloader of ABCL's Lisp class. That will make ABCL's classes visible to it, while retaining the ability to load jars dynamically.

...

There's also my dwimming of classnames that depends on being able to get a list of classes to index.

That might be problematic. Do you iterate through the classpath somehow?

Yes. There are java accessors that tell me the classpath.

Since there's no general means to do that, people usually assume that everything in the classpath has been loaded from a physical jar residing somewhere on the filesystem or the net. OSGi might break that assumption.

How so? Looks like what they actually do is unpack all their jars to a temp directory. Haven't checked yet whether the java accessors will tell me the class path, but if not that information needs to be *somewhere*. -Alan

Alessio

On 5/21/10 1:26 PM, Alan Ruttenberg wrote:

Hi Mark! Thanks a lot!

My pleasure […]

3) Does load bind the readtable? I can't seem to side-effect it when loading jss and so have to type (set-dispatch-macro-character #\# #\" 'read-invoke) to get it to take effect

Both Load.loadSystemFile() and Load.loadFileFromStream() do indeed bind and reset the readtable, but as I understand our code, loading JSS should *always* (even in non-OSGi usage) thunk through loadFileFromStream(), so this shouldn't have different behavior. I currently backporting your addition of jscheme.jar to the version that I can run under the Eclipse debugger to example loading from a PATHNAME-URL actually uses loadFileFromStream() in more detail under the debugger.

4) Having some kind of classpath issues still. When I try (show-classtree "http://purl.obolibrary.org/obo/iao.owl") (after loading my ow2 package sucessfully), which should exercise a bunch of stuff, I get a class not found error in the OWLAPI code.

owlxmlparser/src/main/java/org/coode/owlapi/owlxmlparser/OWLXMLParserFactory.java "java.lang.NoClassDefFoundError: javax/xml/parsers/ParserConfigurationException at org.coode.owlapi.owlxmlparser.OWLXMLParserFactory.createParser(OWLXMLParserFactory.java:39) at uk.ac.manchester.cs.owl.owlapi.ParsableOWLOntologyFactory.getParsers(ParsableOWLOntologyFactory.java:82) at uk.ac.manchester.cs.owl.owlapi.ParsableOWLOntologyFactory.loadOWLOntology(ParsableOWLOntologyFactory.java:158) at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:633) at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntologyFromOntologyDocument(OWLOntologyManagerImpl.java:591) "

This is code that uses jss for the jar management and I have no idea how this interacts with the classpath management of OSGI. I guess OSGI is doing various kinds of isolation and I want to blow all the isolation away :)

I'm failing to load your owl2 definition in a "normal" abcl/SLIME environment. I do the following to setup LSW: 1. Checkout [LSW from SVN][1] under "~/work/lsw/". [1]: http://mumble.net:8080/svn/lsw/trunk 2. Create symbolic links to all of your ASDF definitions unix$ cd ~/work/lsw && find . -name \*.asd -exec ln -s {} \; 3. Add the following to my "~/.abclrc" to find your definitions and set the location of the Pellet library. (defvar cl-user::*pellet-dir* "/Users/evenson/work/lsw/extlib/") (require :asdf) (pushnew '(merge-pathnames "work/lsw/" (user-homedir-pathname)) asdf:*central-registry*) 4. Build ABCL in "~/work/abcl/" with the following line in "abcl.properties" to include jscheme.jar and bsh-2.04b.jar in the default ABCL classpath: additional.jars=../lsw/lib/jscheme.jar:../lsw/lib/bsh-2.0b4.jar 5. Startup ABCL with my own copy of SLIME in Emacs (more current than the SLIME you include with LSW, but I don't expect a difference). 6. Load JSS via ASDF CL-USER> (require :jss) 7. Load "owl2" CL-USER> (require :owl2) This bombs with a ; Loading #P"/Users/evenson/.cache/common-lisp/armedbear-0.21.0-dev-fasl36-darwin-java-1.6/Users/evenson/work/lsw/owl/owl2/parse-mapping-spec.abcl" ... ASDF could not load OWL2 because #<END-OF-FILE {77662FDD}>. for which the relevant part of the stack trace seems to be […] 37: (SYSTEM::%READ-FROM-STRING "\"abc@langTag" T NIL 0 NIL ...) 38: (READ-FROM-STRING "\"abc@langTag") 39: (FLATTEN-TD (("td" . "http://www.w3.org/1999/xhtml") NIL "\"abc@langTag^^" (("i" . "http://www.w3.org/1999/xhtml") NIL "rdf:PlainLiteral"))) 40: (MAPPING-TABLE) […] Any insight on how to get me loading owl2 sucessfully?

I guess I'm bound to lose somehow - I'm dynamically loading the OWLAPI jar, for instance, but protege has it loaded? I guess I can skip loading them with jss if I can figure out how to use the ones that protege has loaded. They are in various plugins.

Right now the jss code looks at the classpath to figure out what jars it should parse to get class names. I suppose by analogy I would look through the bundles for classnames. Is there a way to programmatically determine which bundles are available? To add them programmatically? Or do I need to recompile the plugin to get access to a new plugin?

e.g. I see that I can get a protege editor class: (jclass "org.protege.editor.core.FileUtils") -> #<java class org.protege.editor.core.FileUtils {39C7}>

But jss doesn't know about it:

(find-java-class 'core.fileutils) -> NIL #<ERROR {5D08B1}>

If you have a pointer to your favorite doc about how the OSGI classloading works, please let me know.

Unfortunately, we're going to have to at least co-operate a little bit with OSGi. And I still don't understand OSGi very well either, finding the openly available documentation very poor and not having enough time to go through the source code thoroughly. The Eclipse OSGi implementation (Equinox) seems to have different meanings for parts of MANIFEST.MF. So, anyone with a pointer to decent OSGi documentation, please chime in. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

On Fri, May 21, 2010 at 2:01 PM, Mark Evenson <evenson@panix.com> wrote:

On 5/21/10 1:26 PM, Alan Ruttenberg wrote:

2) Fixed a couple of jss bootstrappy things to make it happy

...

Care to share? Attached is how I patched JSS, but it doesn't seem to load jars from ASDF definitions anymore.

Thought I checked in the changes. Checking now. Yes. It was a matter of not using jss while jss was loading. Seems to work on the surface, but I haven't probed too deeply. I was able to run find-java-class with an abbreviation and return a class.

For the debugging version under Eclipse, I had to go back to including abcl.jar in org.sciencecommons.lisp.protege, otherwise I couldn't seem to get jscheme.jar or bsh-2.0b4.jar to load at all.

Some wierd stuff going on. Maybe I'll have some time this weekend to hunt down what the story with classloaders and OSGI is. To load the owl stuff, use the new lsw project at http://code.google.com/p/lsw2/ Load scripts/system-registry.lisp, then (asdf::oos 'asdf::load-op 'owl2) Ah, maybe you didn't see jss update because you are using lsw on mumble.net . -Alan

On Sat, May 22, 2010 at 5:07 AM, Mark Evenson <evenson@panix.com> wrote:

On 5/21/10 1:26 PM, Alan Ruttenberg wrote:

[…]

...

4) Having some kind of classpath issues still. When I try (show-classtree "http://purl.obolibrary.org/obo/iao.owl") (after loading my ow2 package sucessfully), which should exercise a bunch of stuff, I get a class not found error in the OWLAPI code.

[…]

I think this is fixed with my urn:svn.neurocommons.org:r3437 commit:  I get the pretty Swing graphical rendering of the onotologg to appear.

OSGi's bundling rules require that all uses of packages in the core JavaSE not in java.* have to be explicitly listed in the Import-package statement, so this was a process of running Protege, noting the error, adding to MANIFEST.MF, restarting, and then repeating.  I think I got better error messages than you as I was connecting to the bundle via SLIME, so was able to nose around in the inspector.

The only source of [OSGi documentation of any worth seems to be the specification itself][1].  From sparse reading, I would say that things are pretty grim for supporting the dynamic abilities of JSS code to use other parts of Protege.  As far as I understand things, one needs to explicitly declare uses of other bundles at compile time.  There does seem to be some provisions for locating services, but I don't think this is the way that Protege is coded.

I'm poking at that spec and am making a little progress. First, there's the directive "DynamicImport-Package: *". With that in the bundle I can successfully execute (jclass "javax.xml.xpath.XPathVariableResolver") where I couldn't without it. So perhaps that will work. I guess a test case is to remove the explicit javax imports you had to do and see if it still works. Useful post: http://codescale.wordpress.com/2009/05/22/basics-about-osgi-classloading/ That gave me the phrase "dynamic import" to look for. There's the source code for the bundle loader: http://tinyurl.com/2a4f7q8 And then there's this "resolution:=optional;" bit for bundles, that suggests I might be able to take the list of known bundles and make them all optional . The dynamic import did, however, fail to find a class inside a bundle that I didn't mention (org.coode.annotate.Template). Have to look into that. -Alan

[1]: http://www.osgi.org/download/r4v42/r4.core.pdf

Any sketches of use cases for how you want to extend Protege with this thing?

-- "A screaming comes across the sky.  It has happened before, but there is nothing to compare to it now."