| Classpath problem [message #252678] |
Tue, 15 June 2004 07:40  |
Eclipse User |
|
|
|
Originally posted by: eostroukhov.hotmail.com
Hi all!
We are completing migration to the Eclipse 3.0 runtime and I've had an issue
that was hard to overcome - in our plugin we call an external tool that
needs classpath string as parameter. In old runtime we could typecast plugin
classloader to URL classloader and create that string. In the new runtime I
had to do some hardcodes and I am still not sure as to reliability of the
code:
public static String computeBundleClasspath(final Bundle bundle) {
final String bundleClasspath = (String)
bundle.getHeaders().get(Constants.BUNDLE_CLASSPATH) + ",\nclasses"; // Hack
to support development-time.
StringTokenizer st = new StringTokenizer(bundleClasspath, ",\n,",
false);
StringBuffer classpath = new StringBuffer();
final String bundleLocation =
bundle.getLocation().trim().substring("update@/".length());
while (st.hasMoreElements()) {
classpath.append(bundleLocation).append(st.nextToken().trim( )).append(File.p
athSeparator);
}
return classpath.toString();
}
Is there another way to get classpath string with normal URLs (http, file,
etc.)?
Eugene
|
|
|
| Re: Classpath problem [message #252689 is a reply to message #252678] |
Tue, 15 June 2004 08:17  |
| Eclipse User |
|
|
|
Originally posted by: pascal.ibm.canada
This is the "best" way.
Note that instead of using StringTokenizer you can use the public class
called ManifestElement and its method parseElement(,).
Once you have the jar or folder name, you should get the bundle object
and say Bundle.getEntry(jarName). This will return you a bundle URL that
you then convert to a local url using Platform.asLocalURL().
All the names here have been given by memory so some might be slightly
erroneous. Note that there is a similar code in the class
PluginDescriptor (from memory :-).
HTH,
PaScaL
Eugene Ostroukhov wrote:
> Hi all!
>
> We are completing migration to the Eclipse 3.0 runtime and I've had an issue
> that was hard to overcome - in our plugin we call an external tool that
> needs classpath string as parameter. In old runtime we could typecast plugin
> classloader to URL classloader and create that string. In the new runtime I
> had to do some hardcodes and I am still not sure as to reliability of the
> code:
>
> public static String computeBundleClasspath(final Bundle bundle) {
> final String bundleClasspath = (String)
> bundle.getHeaders().get(Constants.BUNDLE_CLASSPATH) + ",\nclasses"; // Hack
> to support development-time.
> StringTokenizer st = new StringTokenizer(bundleClasspath, ",\n,",
> false);
> StringBuffer classpath = new StringBuffer();
> final String bundleLocation =
> bundle.getLocation().trim().substring("update@/".length());
> while (st.hasMoreElements()) {
>
> classpath.append(bundleLocation).append(st.nextToken().trim( )).append(File.p
> athSeparator);
> }
> return classpath.toString();
> }
>
> Is there another way to get classpath string with normal URLs (http, file,
> etc.)?
>
> Eugene
>
>
|
|
|
|
| Re: Classpath problem [message #252926 is a reply to message #252711] |
Tue, 15 June 2004 18:26 |
| Eclipse User |
|
|
|
Originally posted by: pascal.ibm.canada
Exact. I did not had a coffee yet when I wrote the answer :-)
Rich Kulp wrote:
> Be careful with asLocalURL(), you probably want resolveURL() instead.
> asLocalURL() will make a physical copy of the file if it is not on the
> local machine. While resolveURL() turns it into standard protocol like
> http: or file:
>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.03485 seconds
Home