On 5/21/10 1:26 PM, Alan Ruttenberg wrote:
Hi Mark! Thanks a lot!
My pleasure
[…]
- 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.
- 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.