Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Platform » IStatus not found at runtime
IStatus not found at runtime [message #333308] Wed, 03 December 2008 20:12 Go to next message
Eclipse UserFriend
Originally posted by: eclipse-news.rizzoweb.com

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: IStatus not found at runtime [message #333324 is a reply to message #333308] Thu, 04 December 2008 07:24 Go to previous messageGo to next message
Francis Upton IV is currently offline Francis Upton IVFriend
Messages: 472
Registered: July 2009
Location: Oakland, CA
Senior Member
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


Transitive dependencies and optional plugins [was: IStatus not found at runtime] [message #333442 is a reply to message #333324] Thu, 11 December 2008 14:37 Go to previous messageGo 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 #333528 is a reply to message #333442] 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:Atomic add and configuration of nature
Next Topic:Common Navigator Content Issue
Goto Forum:
  


Current Time: Fri Mar 29 04:48:41 GMT 2024

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

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

Back to the top