Question

I’ve been breaking my head over this for quite a while now and cant find a solution for this problem:

I have an Eclipse RCP application that uses a custom library packaged as jar. From the plugin, i am calling a method within the jar.
Within this method, i am “getting” a resource using this.class.getResource(relPath), whereas relPath is a hardcoded relative path to a file i need. This returns me an URL which i can use to construct a File.

Now, this works perfectly if i am not calling this method from the plugin, but from a simple Java-Program.
The difference: Eclipse RCP’s classloader returns an URL of protocol bundleresource:// which is not supported by File, whereas when running a simple Java-program, a file://-URL is returned which is completely fine to construct a File.

I am aware of the FileLocator-class of the Eclipse SDK (which resolves bundleresource-URLs to file-URLs), but i cannot use it within the library because i dont want to tie it to the Eclipse RCP platform – it should be possible to use this lib from non-Eclipse-RCP sources as well.

Anyone any idea on how i can load this resource from a relative path in a manner that will work both when the method is called from an Eclipse RCP-Plugin or any other client?

I need to construct a File on the directory of this relative path to search for files within. I am completely stuck on this…

UPDATE: If there is a possibility other than using File#list() to get directory contents this would already help me..

any hints greatly appreciated,

Answer 1

Couldn’t you simply invert the dependency. I.e., your module retrieving the resource as URL defines an interface

interface Locator { URL resolve(URL url); }

and you can use a default implementation

class StandaloneLocator implements Locator {
   public URL resolve(URL url) { return url; }
}

In case of Eclipse, this default locator is to be replaced by

class EclipseLocator implements Locator {
  public URL resolve(URL url) { return FileLocator.resolve(url); }
}

Now, your library has no dependencies to Eclipse, and you can still use the FileLocator. Since you won’t get any bundleresource-URLs w/o Eclipse, this should work.

Cheers,
Jens