| Problem exporting plugins from PDE [message #89148] | 
Fri, 01 June 2007 00:51   | 
 
Eclipse User  | 
 | 
 | 
   | 
 
Greetings, 
 
I have a Equinox application that loads a few Jars on the system classpath (e.g., via "-classpath"  
option), and my application uses "osgi.parentClassLoader=app" so that these classes are visible to  
my plugins (via Equinox's default parent-first boot delegation mechanism). While this works at  
runtime (when I handcraft a bundle), I am having trouble trying to create(export) the bundle from  
PDE - the wizard produces several errors (and rightly so!) "The import <foo> cannot be resolved". 
 
How can I configure PDE to indicate the Jars loading via system classpath, so that it can  
successfully generate/export a valid bundle Jar ? 
 
Regards, 
Subbarao
 |  
 |  
  | 
| Re: Problem exporting plugins from PDE [message #89162 is a reply to message #89148] | 
Fri, 01 June 2007 02:28    | 
 
Eclipse User  | 
 | 
 | 
   | 
 
Hi, 
 
If you have this package <foo> in one of your Import-Package clauses, 
then you must have it in one Export-Package. I wonder what is the reason 
that this jars are not made bundles. If your jars are in the app 
classpath, you should export the packages as system packages. These are 
packages exported by system.bundle (or org.eclipse.osgi, these are the 
same thing). The best way to do it is via a framework extension bundle. 
This is fragment, whose Fragment-Host is the system.bundle. It should 
not contain any classes and will only export the package(s) you are 
interested in. 
 
If there isn't any particular reason that the few jars cannot be 
converted as bundles, I strongly encourage you to spend some time 
converting to bundles. After all this what OSGi is made for:) 
 
Danail Nachev 
 
Subbarao Meduri wrote: 
> Greetings, 
>  
> I have a Equinox application that loads a few Jars on the system classpath (e.g., via "-classpath"  
> option), and my application uses "osgi.parentClassLoader=app" so that these classes are visible to  
> my plugins (via Equinox's default parent-first boot delegation mechanism). While this works at  
> runtime (when I handcraft a bundle), I am having trouble trying to create(export) the bundle from  
> PDE - the wizard produces several errors (and rightly so!) "The import <foo> cannot be resolved". 
>  
> How can I configure PDE to indicate the Jars loading via system classpath, so that it can  
> successfully generate/export a valid bundle Jar ? 
>  
> Regards, 
> Subbarao  
>  
>
 |  
 |  
  | 
 | 
 | 
| Re: Problem exporting plugins from PDE [message #90523 is a reply to message #89148] | 
Wed, 13 June 2007 15:37   | 
 
Eclipse User  | 
 | 
 | 
   | 
 
Keep in mind that parent delegation changed in 3.3.  Equinox 3.3 no  
longer defaults to parent-first delegation.  3.3 does do parent-last  
delegation by default instead of totally cutting you off from the parent  
classloader cold turkey.  But this can be disabled as well (and should  
be for a fully compliant OSGi Framework). 
 
The best solution for you moving forward is to add bundle metadata to  
these jars and use them as real OSGi bundles *and* force bundles that  
need packages from these jars to use either Import-Package or  
Require-Bundle. 
 
Pragmatically that may not be possible because your situation may  
require you to support random jars on the classpath.  To mimic this  
behavior in PDE you could create a 'wrapper' PDE project which embeds  
the jars into a bundle which is a fragment to the org.eclipse.osgi  
bundle and exports the additional packages.  This would still require  
your other bundles to import the packages.  You would also have to do  
something at runtime to expose the random jars from the app classloader.  
  This is usually done by installing dummy framework fragments that only  
contain the manifest metadata for exporting the additional packages and  
setting osgi.frameworkParentClassloader=app so that the framework  
classloader has access to the jars from the app classloader. 
 
HTH 
 
Tom
 |  
 |  
  | 
Powered by 
FUDForum. Page generated in 0.07599 seconds