[news.eclipse.tools] Re: jar file location/plugin architecture question

[Vlad Klicnik <klicnik@xxxxxxxxxx>]

Lorna, there are basically 3 ways you could go here ...

(1) make a copy of the jar (the path you suggest but do not like). This is
the simplest.
(2) play the relative path game, where your plugin <library> specification
points to the other .jar. It will work, but this approach will be fragile
(and may need different plugin generated for each user install based on the
location of the IVS jar). I would not recommend this (will be worse than (1))

(3) do your own class loading. As part of your plugin startup(), you can
create a new URLClassLoader and use the "external" jar(s) as its search path.
If the external jar makes references to eclipse APIs, you can parent the new
loader with your plugin class loader (in your startup can do
this.getClass().getClassLoader(), or look the plugin descriptor via the
plugin registry and do IPluginDescriptor.getPluginClassLoader()). That way
your plugin <requires> specification can drag in whatever eclipse plugins the
external jar needs. If the external jar is just a "self-contained" callable
library, then the new loader can just use default parenting (ie. specify null
for the parent loader). You will not be able to make direct compiler
references to the code in the external jar (that is because your code that is
loaded by the "regular" plugin loader does not have the external jar on its
search path). You'll need to use the new loader to load the class(es) you
interact with, and then call by reflection. This is bit of a pain, but with a
bit of planning one can usually minimize the number of the reflective calls
required/ the amount of wrapper code you'd need to write.

We are investigating various options to support execution structures similar
to what you describe.

Lorna Reyes wrote:

> Any suggestions about this scenario?
>
> We expect the user has WSAD installed on the machine, and then install
> ISV's product. We want to keep ISV's jar file under ISV's installation
> directory, and also create the necessary plugins for ISV/WSAD integration
> during ISV installation time. If we can not specify a jar file which is
> located outside of WSAD directory, we will need to have two copies of
> ISV's jar file. That is
> something we want to avoid.  Is there a way to work around this problem ?
>
> Thanks.
> Lorna