[news.eclipse.tools] Re: Problems with getInstallURL()

[Vlad Klicnik <klicnik@xxxxxxxxxx>]

Ilya, below is some information/ rationale for the change.

The reason we introduced the "eclipse" schema is precisely because most code
(incl. our own platform code) would simply take the install URL and convert
it to a local file. Although plugin directories will usually be local, they
ARE NOT GUARANTEED TO BE ALWAYS LOCAL, so doing getInstallURL().getFile() is
meaningless in the general case. The install URLs should be used as URLs, not
as a way to get a file name.

In most (99%) of the cases people should be doing (new
URL(get.installURL(),"my.file")).openStream() instead, or use the class
loaders to access resources in the install directory (load from its plugin
.jar, or can in fact create its own loaders for any "special purpose" loading
... new URLClassLoader(pd.getInstallURL()) and then use it to load the
resources that are not in the jar).

Only in the exception case, should people try to do anything else. We have
come across 2 cases ourselves. One is where the file we are accessing cannot
be handled as a stream (eg. java native .dll's that need to be loaded). The
other are cases where you may want to access the install URL from an
environment that does not support the "eclipse" schema, so you need give out
the "real" URL. For these, we have 2 API methods (I think introduced in
platform build 0.039)

URL Platform.resolve(URL)
URL Platform.asLocalURL(URL)

The first simply returns the "real" URL ... eg.
"http://some.server/some.plugins.dir/some.file";.

The second is an API version of the internal call that sould be in the build
you have (on EclipseURLConnection). The method will cache, if needed, the
references file and return it as "file" URL. We use this for handling .dll's
and few places where plugins supply/ call .exe's. People should only be using
this method when they have to have "file" URL because they cannot do stream
i/o. They should NOT be using it in the general case.