[armedbear-devel] Changes committed to org.sciencecommons.lisp.protege

[Alan Ruttenberg]

On Sat, May 22, 2010 at 5:07 AM, Mark Evenson <evenson at 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."
>