| passing plugin classpath to a forked JVM [message #134293] |
Tue, 23 September 2003 08:55  |
Eclipse User |
|
|
|
Originally posted by: christian.sell.netcologne.de
Hello,
I am launching a Java subprocess from within my plugin, and would like
to set the classpath of the forked VM to some of the same libraries that
are visible to my plugin. I am querying the plugin libraries with
plugin.getPluginDescriptor().getRuntimeLibraries(), and encounter the
following problems:
1. The plugin jar files are not accessible as disk file paths, but only
through URLs that use a custom protocol (platform:...).
2. At least during development, the plugin classes themselves are not
available as jar files at all.
Therfore my questions:
- is there a way to make the locations of the jar files from the plugin
install directory visible/readable for external programs, such as a
forked VM?
- (less important and likely) is there a way to externalize the location
of the compiled files used by eclipse during development
I would really like to get along without having to depend on or copy the
JDT code.. thanks in advance for any hints,
Christian
|
|
|
| Re: passing plugin classpath to a forked JVM [message #134336 is a reply to message #134293] |
Tue, 23 September 2003 09:34  |
| Eclipse User |
|
|
|
to partly answer my own question:
for problem #1, Platform.resolve(url) is at least one step in the right
direction. Still not clear how to create a classpath from non-file-URLs,
though..
Christian Sell wrote:
> Hello,
>
> I am launching a Java subprocess from within my plugin, and would like
> to set the classpath of the forked VM to some of the same libraries that
> are visible to my plugin. I am querying the plugin libraries with
> plugin.getPluginDescriptor().getRuntimeLibraries(), and encounter the
> following problems:
>
> 1. The plugin jar files are not accessible as disk file paths, but only
> through URLs that use a custom protocol (platform:...).
>
> 2. At least during development, the plugin classes themselves are not
> available as jar files at all.
>
> Therfore my questions:
>
> - is there a way to make the locations of the jar files from the plugin
> install directory visible/readable for external programs, such as a
> forked VM?
>
> - (less important and likely) is there a way to externalize the location
> of the compiled files used by eclipse during development
>
> I would really like to get along without having to depend on or copy the
> JDT code.. thanks in advance for any hints,
>
> Christian
>
|
|
|
|
|
| Re: passing plugin classpath to a forked JVM [message #134434 is a reply to message #134347] |
Tue, 23 September 2003 10:36 |
| Eclipse User |
|
|
|
thanks. Could you elaborate a little on what you mean by "add the url to
your forked VM classpath" - to my knowledge the classpath command line
option only accepts file system paths?
And while we're at it, how to I determine my plugin projects output
(bin) directory?
thanks,
Christian
Chris Laffra wrote:
> Try something like this:
>
> IPluginDescriptor descriptor = Plugin.getDefault().getDescriptor();
> ILibrary[] libraries = descriptor.getRuntimeLibraries();
> URL installUrl = Platform.resolve(descriptor.getInstallURL());
>
> for (int i = 0; i < libraries.length; ++i)
> {
> try
> {
> File file = libraries[i].getPath().toFile();
> URL url = new URL(installUrl, file.toString());
> // add the url to your forked VM classpath
> }
> catch (Exception e)
> {
> e.printStackTrace();
> }
> }
>
>
> Chris
>
>
> "Christian Sell" <christian.sell@netcologne.de> wrote in message
> news:bkpfqs$304$1@eclipse.org...
>
>>Hello,
>>
>>I am launching a Java subprocess from within my plugin, and would like
>>to set the classpath of the forked VM to some of the same libraries that
>>are visible to my plugin. I am querying the plugin libraries with
>>plugin.getPluginDescriptor().getRuntimeLibraries(), and encounter the
>>following problems:
>>
>>1. The plugin jar files are not accessible as disk file paths, but only
>>through URLs that use a custom protocol (platform:...).
>>
>>2. At least during development, the plugin classes themselves are not
>>available as jar files at all.
>>
>>Therfore my questions:
>>
>>- is there a way to make the locations of the jar files from the plugin
>>install directory visible/readable for external programs, such as a
>>forked VM?
>>
>>- (less important and likely) is there a way to externalize the location
>>of the compiled files used by eclipse during development
>>
>>I would really like to get along without having to depend on or copy the
>>JDT code.. thanks in advance for any hints,
>>
>>Christian
>>
>
>
>
|
|
|
| Re: passing plugin classpath to a forked JVM [message #134782 is a reply to message #134293] |
Tue, 23 September 2003 22:00 |
| Eclipse User |
|
|
|
Originally posted by: bnfb.cs.washington.edu
Christian,
Here's how we solved the same issue (launching a Java subprocess and using
the same paths):
First, we read Darin Wright's article about launching Java subprocesses
( http://www.eclipse.org/articles/Article-Java-launch/launchin g-java.html).
Second, we build the classpath using conditionals to determine whether we
are in development model (running under the PDE) or in delivery mode (using
the plugin jar). Here's a fragment:
// Look for the compiled jar - this will exist if I am running in a plug-in
URL jar_url = plugin.find(new Path(MY_JAR_NAME));
if (jar_url != null) {
File jar = new File(jar_url.getPath());
if (jar.exists()) {
IPath path = new Path(jar_url.getPath());
IRuntimeClasspathEntry entry =
JavaRuntime.newArchiveRuntimeClasspathEntry(path);
classpath.add(urbansimEntry.getMemento());
}
} else {
// Look for the project bin directory - this will exist if I am running
under the PDE
// Note that we are looking for the project directory that is the source of
the plug-in
// that is running under the PDE, thus we look in "workspace/". If we did
not take off
// the last segment we would be looking in "runtime-workspace/" which is not
where
// the source code for *this* plug-in is.
File src = new File(
workspace
.getRoot()
.getLocation()
.removeLastSegments(1)
.toString()
+ "workspace/MyProject");
if (src.exists()) {
IPath path = new Path(src.getPath() + "/bin/");
IRuntimeClasspathEntry entry =
JavaRuntime.newArchiveRuntimeClasspathEntry(path);
classpath.add(entry.getMemento());
}
}
There are some obvious places where this solution could be cleaned up but
being a pragmatist, this works for me so the clean up will probably never
get time allocated. Improvements would be: (1) getting the MY_JAR_NAME from
the project build information rather than as a string constant; (2) getting
the project name from the project rather than using a string; (3) not
depending on the class file location being "/bin/"; (4) not depending on the
workspace directory being named "workspace".
Regards,
Bjorn Freeman-Benson
Center for Urban Simulation and Policy Analysis (http://www.urbansim.org/)
|
|
|
Powered by
FUDForum. Page generated in 0.05630 seconds
Home