--- Thomas DeWeese <Thomas.DeWeese@xxxxxxxxx> wrote:
> I don't know anything about how JEdit does it thing, but is it possible
> that the way it sets up the class path 'partitions' the class loaders
> in some way? So batik-bridge.jar can see batik-util.jar but not the
> other way round (a bit like the UNIX link line).
Hmmm. I bet it must be an issue with some kind of custom class loading. When
jEdit loads a plugin, class library dependencies are done by putting the jars
in a standard "jars" directory (the same one with the actually plugin jar).
When jEdit starts up, it goes through this directory and loads what it needs.
You get a message on the jEdit activity log that it scanned the jars.
In particular, I bet they aren't actually on the classpath.
> Also are these the standard batik jar files or are you rolling your
> own some how (it looks like they are the standard jar files). It may be
> important as the resource files are stored in a separate directory tree
> from the class files so it isn't 'trivial' to build the jar files correctly.
I'm using most of the jars in the batik-1.5/lib directory. The ones relevant to
this error are the batik-bridge.jar and batik-util.jar. I can actually use
jEdit to browse right in to the jars I'm using and see that the
Messages.properties is where it should be. I even wrote some code which does
nothing but tries to retrieve the message, and this code works.
> Not much help really, sorry :)
Actually, you gave me a direction to go and look at. Unfortunately, I'm not
sure what to do if I conclude "yes, jEdit is using a class loader that prevents
the bundle from being visible". I can't really change this aspect of jEdit.
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
|
