Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Plugin Development Environment (PDE) » Transitive dependencies and optional plugins [was: IStatus not found at runtime]
Transitive dependencies and optional plugins [was: IStatus not found at runtime] [message #37067] Thu, 11 December 2008 14:37 Go to next message
Eclipse UserFriend
Originally posted by: eclipse-news.rizzoweb.com

It turns out to be a transitive dependency issue. The problem was only
happening on Mac OS X, which really confused me. Here's what was going on:
Our plugins use the EPF RichText feature, which itself declares
dependencies on several "core" Eclipse plugins, among them
org.eclipse.core.runtime, where IStatus lives. The RichText plugin
re-exports all of those dependencies, which means they are picked up
automatically by our own plugin that uses RichText, org.skyway.ui, which
also re-exports RichText (probably should not, I guess).
The plugin that I reported about giving the NoClassDefFoundError depends
on org.skyway.ui, which means it was transitively inheriting the
dependency on org.eclipse.core.runtime; usage of classes like IStatus
would compile and launching from the IDE worked fine.
Now here the kicker: the EPF RichText plugin does not install/load on OS
X; I've got code in org.skyway.ui to detect that and gracefully fall
back to plain Text, but what that means at runtime is that any plugin
that depended on org.skyway.ui and had inherited the twice-reexported
org.eclipse.core.runtime, could not find org.eclipse.core.runtime
(unless that plugin had explicitly declared a dependency on
org.eclipse.core.runtime).
It's even more of a problem because the manifest editor does not let me
add the dependency on org.eclipse.core.runtime, presumably because it
"knows" I have a transitive dependency on it already. And it turns out
there are a handful of other plugins besides org.eclipse.core.runtime
that RichText re-exports and caused the same problem.

This seems to me like a hole in the PDE tools, because it took a lot of
digging and thinking and simple luck to find out what was going on. It
seems that if pluginA is inheriting a dependency from pluginB because
pluginB re-exports it, and pluginB is optional, then the tooling should
alert you to the fact that at runtime pluginA may not have access to the
dependency.

Any thoughts? Advice for avoiding this pitfall?

Eric


On 12/4/2008 2:24 AM, Francis Upton (News) wrote:
> I think the IStatus is a red herring, something else is probably missing
> or not setup right in the dependencies for the plugin. Carefully check
> that all of the dependencies specified in the plugin's manifest are
> there. And also check the log for any other missing plugins.
>
> The IDE environment is totally different because you could be getting
> all of your plugins loaded.
>
> HTH,
> Francis
>
> Eric Rizzo wrote:
>> The product I'm working on has several plugins, and not surprisingly
>> they all use or depend on org.eclipse.core.runtime.IStatus.
>> So I've just added a new UI plugin, and its Activator code is copied
>> from other activators we've written. In particular, it has references
>> to IStatus. This plugin compiles fine and works when launched from the
>> IDE; but at runtime, when installed into an existing Eclipse instance,
>> it throws a "NoClassDefFoundError: org/eclipse/core/runtime/IStatus"
>> when trying to activate the this one plugin.
>>
>> Any ideas what could be the cause? The plugin does not specify a
>> dependency on the org.eclipse.core.runtime bundle, but it does compile
>> anyway (and I verified that our other UI plugins don't depend on that
>> one, either).
>>
>> Thanks in advance,
>> Eric
>>
>>
>>
>>
>
>
Re: Transitive dependencies and optional plugins [was: IStatus not found at runtime] [message #37890 is a reply to message #37067] Tue, 16 December 2008 21:07 Go to previous message
Francis Upton IV is currently offline Francis Upton IVFriend
Messages: 472
Registered: July 2009
Location: Oakland, CA
Senior Member
I would ask a top-level question on the PDE newsgroup.

Eric Rizzo wrote:
> It turns out to be a transitive dependency issue. The problem was only
> happening on Mac OS X, which really confused me. Here's what was going on:
> Our plugins use the EPF RichText feature, which itself declares
> dependencies on several "core" Eclipse plugins, among them
> org.eclipse.core.runtime, where IStatus lives. The RichText plugin
> re-exports all of those dependencies, which means they are picked up
> automatically by our own plugin that uses RichText, org.skyway.ui, which
> also re-exports RichText (probably should not, I guess).
> The plugin that I reported about giving the NoClassDefFoundError depends
> on org.skyway.ui, which means it was transitively inheriting the
> dependency on org.eclipse.core.runtime; usage of classes like IStatus
> would compile and launching from the IDE worked fine.
> Now here the kicker: the EPF RichText plugin does not install/load on OS
> X; I've got code in org.skyway.ui to detect that and gracefully fall
> back to plain Text, but what that means at runtime is that any plugin
> that depended on org.skyway.ui and had inherited the twice-reexported
> org.eclipse.core.runtime, could not find org.eclipse.core.runtime
> (unless that plugin had explicitly declared a dependency on
> org.eclipse.core.runtime).
> It's even more of a problem because the manifest editor does not let me
> add the dependency on org.eclipse.core.runtime, presumably because it
> "knows" I have a transitive dependency on it already. And it turns out
> there are a handful of other plugins besides org.eclipse.core.runtime
> that RichText re-exports and caused the same problem.
>
> This seems to me like a hole in the PDE tools, because it took a lot of
> digging and thinking and simple luck to find out what was going on. It
> seems that if pluginA is inheriting a dependency from pluginB because
> pluginB re-exports it, and pluginB is optional, then the tooling should
> alert you to the fact that at runtime pluginA may not have access to the
> dependency.
>
> Any thoughts? Advice for avoiding this pitfall?
>
> Eric
>
>
> On 12/4/2008 2:24 AM, Francis Upton (News) wrote:
>> I think the IStatus is a red herring, something else is probably missing
>> or not setup right in the dependencies for the plugin. Carefully check
>> that all of the dependencies specified in the plugin's manifest are
>> there. And also check the log for any other missing plugins.
>>
>> The IDE environment is totally different because you could be getting
>> all of your plugins loaded.
>>
>> HTH,
>> Francis
>>
>> Eric Rizzo wrote:
>>> The product I'm working on has several plugins, and not surprisingly
>>> they all use or depend on org.eclipse.core.runtime.IStatus.
>>> So I've just added a new UI plugin, and its Activator code is copied
>>> from other activators we've written. In particular, it has references
>>> to IStatus. This plugin compiles fine and works when launched from the
>>> IDE; but at runtime, when installed into an existing Eclipse instance,
>>> it throws a "NoClassDefFoundError: org/eclipse/core/runtime/IStatus"
>>> when trying to activate the this one plugin.
>>>
>>> Any ideas what could be the cause? The plugin does not specify a
>>> dependency on the org.eclipse.core.runtime bundle, but it does compile
>>> anyway (and I verified that our other UI plugins don't depend on that
>>> one, either).
>>>
>>> Thanks in advance,
>>> Eric
>>>
>>>
>>>
>>>
>>
>>
>


--
*new* Common Navigator Framework section in:
3.4RC4 Platform Plugin Developer Guide (Programmer's Guide)
http://help.eclipse.org/ganymede/topic/org.eclipse.platform. doc.isv/guide/cnf.htm
http://dev.eclipse.org/blogs/francis
http://wiki.eclipse.org/Common_Navigator_Framework
http://wiki.eclipse.org/Common_Navigator_Framework_Use_Cases


You have brains in your head.
You have feet in your shoes.
- Dr Seuss, Oh the Places You'll Go


Re: Transitive dependencies and optional plugins [was: IStatus not found at runtime] [message #587242 is a reply to message #37067] Tue, 16 December 2008 21:07 Go to previous message
Francis Upton IV is currently offline Francis Upton IVFriend
Messages: 472
Registered: July 2009
Location: Oakland, CA
Senior Member
I would ask a top-level question on the PDE newsgroup.

Eric Rizzo wrote:
> It turns out to be a transitive dependency issue. The problem was only
> happening on Mac OS X, which really confused me. Here's what was going on:
> Our plugins use the EPF RichText feature, which itself declares
> dependencies on several "core" Eclipse plugins, among them
> org.eclipse.core.runtime, where IStatus lives. The RichText plugin
> re-exports all of those dependencies, which means they are picked up
> automatically by our own plugin that uses RichText, org.skyway.ui, which
> also re-exports RichText (probably should not, I guess).
> The plugin that I reported about giving the NoClassDefFoundError depends
> on org.skyway.ui, which means it was transitively inheriting the
> dependency on org.eclipse.core.runtime; usage of classes like IStatus
> would compile and launching from the IDE worked fine.
> Now here the kicker: the EPF RichText plugin does not install/load on OS
> X; I've got code in org.skyway.ui to detect that and gracefully fall
> back to plain Text, but what that means at runtime is that any plugin
> that depended on org.skyway.ui and had inherited the twice-reexported
> org.eclipse.core.runtime, could not find org.eclipse.core.runtime
> (unless that plugin had explicitly declared a dependency on
> org.eclipse.core.runtime).
> It's even more of a problem because the manifest editor does not let me
> add the dependency on org.eclipse.core.runtime, presumably because it
> "knows" I have a transitive dependency on it already. And it turns out
> there are a handful of other plugins besides org.eclipse.core.runtime
> that RichText re-exports and caused the same problem.
>
> This seems to me like a hole in the PDE tools, because it took a lot of
> digging and thinking and simple luck to find out what was going on. It
> seems that if pluginA is inheriting a dependency from pluginB because
> pluginB re-exports it, and pluginB is optional, then the tooling should
> alert you to the fact that at runtime pluginA may not have access to the
> dependency.
>
> Any thoughts? Advice for avoiding this pitfall?
>
> Eric
>
>
> On 12/4/2008 2:24 AM, Francis Upton (News) wrote:
>> I think the IStatus is a red herring, something else is probably missing
>> or not setup right in the dependencies for the plugin. Carefully check
>> that all of the dependencies specified in the plugin's manifest are
>> there. And also check the log for any other missing plugins.
>>
>> The IDE environment is totally different because you could be getting
>> all of your plugins loaded.
>>
>> HTH,
>> Francis
>>
>> Eric Rizzo wrote:
>>> The product I'm working on has several plugins, and not surprisingly
>>> they all use or depend on org.eclipse.core.runtime.IStatus.
>>> So I've just added a new UI plugin, and its Activator code is copied
>>> from other activators we've written. In particular, it has references
>>> to IStatus. This plugin compiles fine and works when launched from the
>>> IDE; but at runtime, when installed into an existing Eclipse instance,
>>> it throws a "NoClassDefFoundError: org/eclipse/core/runtime/IStatus"
>>> when trying to activate the this one plugin.
>>>
>>> Any ideas what could be the cause? The plugin does not specify a
>>> dependency on the org.eclipse.core.runtime bundle, but it does compile
>>> anyway (and I verified that our other UI plugins don't depend on that
>>> one, either).
>>>
>>> Thanks in advance,
>>> Eric
>>>
>>>
>>>
>>>
>>
>>
>


--
*new* Common Navigator Framework section in:
3.4RC4 Platform Plugin Developer Guide (Programmer's Guide)
http://help.eclipse.org/ganymede/topic/org.eclipse.platform. doc.isv/guide/cnf.htm
http://dev.eclipse.org/blogs/francis
http://wiki.eclipse.org/Common_Navigator_Framework
http://wiki.eclipse.org/Common_Navigator_Framework_Use_Cases


You have brains in your head.
You have feet in your shoes.
- Dr Seuss, Oh the Places You'll Go


Previous Topic:Build Feature which includes pre-built feature w/OS-specific plugins
Next Topic:Any way to insert SCM revision # as qualifier per plugin/feature not globally?
Goto Forum:
  


Current Time: Tue Apr 23 08:25:39 GMT 2024

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

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

Back to the top