Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 349603

Summary:	Changed behavior when specifying runtime library in plugin.xml
Product:	[Eclipse Project] Platform	Reporter:	Nadeem Aboobaker <nadeem.aboobaker>
Component:	Runtime	Assignee:	platform-runtime-inbox <platform-runtime-inbox>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	normal
Priority:	P3	CC:	pwebster, tjwatson
Version:	3.7
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Nadeem Aboobaker

2011-06-16 13:48:21 EDT

Over the last 6-7 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 using relative paths and they export all packages, like so:

I know that using the plugin.xml to specify runtime libraries is deprecated in favor of using the manifest.mf bundle-classpath. Additionally, the practice of using relative paths in the plugin.xml to reach the jars is probably just discouraged or not officially supported. 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 and there aren't any Java compile errors when referencing those classes. However, at runtime, usage of these classes 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.

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.

Comment 1 Thomas Watson

2011-06-16 13:59:48 EDT

We intentionally fixed a security bug that this "feature" was exploiting.  If you have a common library that several bundles need then why not have it packages in a single bundle which your other bundles can depend on?

*** This bug has been marked as a duplicate of bug 342114 ***

Comment 2 Nadeem Aboobaker

2011-06-16 14:26:24 EDT

Thanks for the answer to my question.  Now that I know it was intentional, I can go about converting the usage runtime libraries in plugin.xml to bundle classpath entries in manifest.mf.

As for your suggestion, my issue isn't about having multiple bundles vs. a single bundle, it's about referencing jars outside of the bundle.  My use case is that we have our runtime jars that are shared by multiple components of our product, with one of those components being our Eclipse tooling.  So, we can't move those jars into our bundles.  We could make copies of the jars in our bundles, but having multiple copies of the jars floating around isn't ideal.

I know that I can use the "external" keyword for Bundle-Classpath entries in the manifest.mf file.  But in Bug 342114, you made a comment "We do not
support adding classpath entries that are outside of the content of our bundle."  You also made a comment about it breaking modularity and strongly advise against using "external" in Bug 109743.  So, am I at the "last resort" point and use "external" or is there something else I can try?

Comment 3 Thomas Watson

2011-06-16 14:45:55 EDT

(In reply to comment #2)
> So, am I at the "last resort"
> point and use "external" or is there something else I can try?

Sorry, it seems you are at the last resort option.  If you cannot move the jar into a bundle at all then this is the only option I can think of at the moment.

Comment 4 Paul Webster

2011-06-17 07:56:09 EDT

(In reply to comment #2)
> As for your suggestion, my issue isn't about having multiple bundles vs. a
> single bundle, it's about referencing jars outside of the bundle.  My use case
> is that we have our runtime jars that are shared by multiple components of our
> product, with one of those components being our Eclipse tooling.  So, we can't
> move those jars into our bundles.  We could make copies of the jars in our
> bundles, but having multiple copies of the jars floating around isn't ideal.

Another suggestion (you might not be able to take advantage of it) is to provide OSGi manifests for all of the other jars in your product.  As far as the rest of your product is concerned, they'll just be jars with extra headers in the MANIFEST.MF.

But when installed into OSGi/eclipse, they'll be full participants without needing hacks.  This only works if providing manifests doesn't cause inter-jar classpath issues in the jars themselves.

PW