Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Platform » Indigo changes in plugin.xml and runtime library?
Indigo changes in plugin.xml and runtime library? [message #684621] Wed, 15 June 2011 23:51 Go to next message
Nadeem Aboobaker is currently offline Nadeem AboobakerFriend
Messages: 20
Registered: July 2009
Junior Member
Over the last 6+ years, we've developed many Eclipse plugins for our product. As a result, the plugins are a mix of old style plugins (i.e., a plugin.xml that defines the ID, runtime libraries, plugin dependencies, etc.) and newer style bundles (where plugin.xml is just for the extensions, and manifest.mf is for defining the ID, bundle-classpath, required-bundles, etc.).

Most of the plugins have been changed to the newer style bundles, but we have a few plugins that are mainly used as jar libraries, in that they specify many runtime libraries that export all packages, like so:

<runtime>
<library name="../lib/some-library-A_1.1.jar"><export name="*"/></library>
<library name="../../some-library-B_1.2.jar"><export name="*"/></library>
...
</runtime>

I'm sure the practice of using the plugin.xml to specify runtime libraries is discouraged in favor of using the manifest.mf bundle-classpath. Additionally, I'm sure the practice of exporting * is also discouraged. And lastly, the practice of using relative paths to reach the jars is probably just another discouraged practice. But, this was working for us just fine through Eclipse 3.6.2.

Now, we're using milestone builds of Eclipse Indigo 3.7, and I've found that using relative paths in the plugin.xml no longer works. In the PDE, things work just fine, classes are resolved from the jars specified with the relative paths. However, at runtime, this just results in class not found problems.

In my experimentation, I've found that copying a jar file into the plugin folder and specifying the runtime library as existing in the current directory fixes the problem. However, I can't do this in my final product, as there are literally hundreds of JARs that are referenced in the installed product and they need to stay where they are, and making duplicate copies inside of the plugins is not an option either.

So, my first question is this: Was removing the ability to load runtime libraries using relative paths an intentional decision in Indigo? I tried to search the forums, bug database, and Google to find any notes on this topic, but haven't been able to find anything.

If the answer is that this is an intentional change, I'm assuming that I'll then need to migrate these hundreds of lines from a plugin.xml to a manifest.mf. I need to maintain the ability to reference jars external to the plugin folder and export all packages. I've done a bit of searching on that as well, and I've found that one can use the "external:" keyword on the BundleClasspath, but haven't seen a way of exporting all packages, short of manually enumerating every package. Any help?

Thanks in advance,
Nadeem
Re: Indigo changes in plugin.xml and runtime library? [message #684869 is a reply to message #684621] Thu, 16 June 2011 11:34 Go to previous messageGo to next message
Paul Webster is currently offline Paul WebsterFriend
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member

The plugin.xml spec was deprecated in favour of the MANIFEST.MF in 3.0 ... that was 7 years ago.

AFAIK there is no way to simply export all packages in the manifest spec. But PDE tools will scan all of your jars and you can then export all packages (it'll just list everything in your jars Smile

If the jars in question are 3rd party jars that are sitting on the client system, then "external:" is the way to go.

My advice is, you should change this (about 4 years ago Smile No one cares about the old runtime plugin format, and apparently we're not using it either.

But I don't remember if they deliberately walked away from it, or if changes to the system simply prevent certain paths from working. Just because it used to work, doesn't mean it was supposed to. It only matters what it is spec'ed to do.

But it's worth opening a bug at https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Platform&component=Runtime

PW


Re: Indigo changes in plugin.xml and runtime library? [message #685070 is a reply to message #684869] Thu, 16 June 2011 18:57 Go to previous message
Nadeem Aboobaker is currently offline Nadeem AboobakerFriend
Messages: 20
Registered: July 2009
Junior Member
Paul, thanks for the reply. I've known for years that we'd eventually have to make the switch and was just waiting for the Eclipse runtime to force it. Smile I opened Bug 349603 and Thomas Watson replied saying it was an intentional security fix and he also confirmed my scenario would require using the "external" keyword.

Just wondering, should I file bugs against the PDE? Right now the PDE is inconsistent with the runtime in that 1.) the PDE has no problems with the relative paths and 2.) the command line PDE ant runner build also has no problems building plugins that use the relative paths. I'm assuming the PDE command line build should fail, and the PDE should show errors in the Problems View when my code references classes from these relative path jars in the plugin.xml.
Previous Topic:Eclipse menuitem action on buttons
Next Topic:Popup menu action visibility problem
Goto Forum:
  


Current Time: Thu Apr 18 07:27:18 GMT 2024

Powered by FUDForum. Page generated in 0.02438 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top