You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Eric Berryman <er...@gmail.com> on 2014/06/23 21:07:54 UTC
CNFE org.eclipse.core.runtime.Plugin
Maybe I'm doing something wrong .... I'm trying to use the
maven-osgi-plugin to bundle a jar in maven and add an activator to set some
preferences. After adding to an Eclipse RCP project, I get a CNFE for the
org.eclipse.core.runtime.Plugin when the activator tries to run:
Caused by: java.lang.NoClassDefFoundError: org/eclipse/core/runtime/Plugin
I was guessing this is an import issue, but that looks fine:
Import-Package: javax.swing,org.eclipse.core.runtime;common=split;vers
ion="3.4",org.eclipse.core.runtime.preferences;version="3.3",org.osgi.fra
mework;version="1.6"
If I use Embed-Dependency for the eclipse jars, everything works fine. Is
there something I should know about Eclipse dependencies?
Also, I used eclipse:to-maven to make a maven repo of all Eclipse 3.7.2
RCP/RAP, and this is where my eclipse artifacts get resolved from.
I would be grateful for any help understanding the issue here.
Re: CNFE org.eclipse.core.runtime.Plugin
Posted by Eric Berryman <er...@gmail.com>.
Thank you very much! Everything passes on Jenkins!
(and thank you for the full explanation)
On Mon, Jun 23, 2014 at 5:52 PM, Neil Bartlett <nj...@gmail.com> wrote:
> Hi Eric,
>
> The explanation for this error is quite involved, so I’ll give you a
> tl;dr. You need to add the following to your instructions for the
> bundle-plugin:
>
>
> <Import-Package>*;ui.workbench=!;common=!;registry=!;texteditor=!;text=!</Import-Package>
>
> Now the explanation, fasten your seatbelt.
>
> Eclipse suffers massively from split packages as a consequence of using
> Require-Bundle for all their dependencies rather than Import-Package, which
> everybody knows is the right way to describe dependencies in OSGi. One
> example of this is the org.eclipse.core.runtime package, which is split
> across the two bundles org.eclipse.equinox.common and
> org.eclipse.equinox.registry. They both export part of the package, but
> they do so with a mandatory attribute of “common” and “registry”
> respectively.
>
> Fortunately there is a bundle that aggregates the split package: this is
> the org.eclipse.core.runtime bundle (here it’s easy to get confused because
> the bundle has the same ID as the package we are talking about). The core
> runtime bundle exports the *whole* package and it does so without any
> mandatory attributes. This is good because if you do a plain old
> “Import-Package: org.eclipse.core.runtime” then you get the whole package
> and everything works fine.
>
> Unfortunately bnd (on which the maven-bundle-plugin is based) does
> something which is… err… of debatable merit. When it sees you build against
> a bundle which has a mandatory attribute on its export, it assumes that you
> must want to import that package and therefore it adds the attribute on
> your Import-Package. You can see this in your manifest with the
> “common=split” after the package name.
>
> As a result, OSGi wires you to the partial package exported by the
> org.eclipse.equinox.common bundle, which doesn’t contain the Plugin class
> and therefore you get the CNFE.
>
> The solution I gave at the top simply overrides bnd’s default behaviour
> and tells it not to add the mandatory attribute. It also includes a bunch
> of other rules that I have found are necessary due to other splits in the
> Eclipse/Equinox bundles.
>
> I hope that helps and made some kind of sense.
>
> Regards,
> Neil
>
>
> On 23 June 2014 at 20:08:41, Eric Berryman (eric.berryman@gmail.com)
> wrote:
>
> Maybe I'm doing something wrong .... I'm trying to use the
> maven-osgi-plugin to bundle a jar in maven and add an activator to set
> some
> preferences. After adding to an Eclipse RCP project, I get a CNFE for the
> org.eclipse.core.runtime.Plugin when the activator tries to run:
>
> Caused by: java.lang.NoClassDefFoundError: org/eclipse/core/runtime/Plugin
>
> I was guessing this is an import issue, but that looks fine:
>
> Import-Package: javax.swing,org.eclipse.core.runtime;common=split;vers
> ion="3.4",org.eclipse.core.runtime.preferences;version="3.3",org.osgi.fra
> mework;version="1.6"
>
> If I use Embed-Dependency for the eclipse jars, everything works fine. Is
> there something I should know about Eclipse dependencies?
>
> Also, I used eclipse:to-maven to make a maven repo of all Eclipse 3.7.2
> RCP/RAP, and this is where my eclipse artifacts get resolved from.
>
> I would be grateful for any help understanding the issue here.
>
>
Re: CNFE org.eclipse.core.runtime.Plugin
Posted by Neil Bartlett <nj...@gmail.com>.
Hi Eric,
The explanation for this error is quite involved, so I’ll give you a tl;dr. You need to add the following to your instructions for the bundle-plugin:
<Import-Package>*;ui.workbench=!;common=!;registry=!;texteditor=!;text=!</Import-Package>
Now the explanation, fasten your seatbelt.
Eclipse suffers massively from split packages as a consequence of using Require-Bundle for all their dependencies rather than Import-Package, which everybody knows is the right way to describe dependencies in OSGi. One example of this is the org.eclipse.core.runtime package, which is split across the two bundles org.eclipse.equinox.common and org.eclipse.equinox.registry. They both export part of the package, but they do so with a mandatory attribute of “common” and “registry” respectively.
Fortunately there is a bundle that aggregates the split package: this is the org.eclipse.core.runtime bundle (here it’s easy to get confused because the bundle has the same ID as the package we are talking about). The core runtime bundle exports the *whole* package and it does so without any mandatory attributes. This is good because if you do a plain old “Import-Package: org.eclipse.core.runtime” then you get the whole package and everything works fine.
Unfortunately bnd (on which the maven-bundle-plugin is based) does something which is… err… of debatable merit. When it sees you build against a bundle which has a mandatory attribute on its export, it assumes that you must want to import that package and therefore it adds the attribute on your Import-Package. You can see this in your manifest with the “common=split” after the package name.
As a result, OSGi wires you to the partial package exported by the org.eclipse.equinox.common bundle, which doesn’t contain the Plugin class and therefore you get the CNFE.
The solution I gave at the top simply overrides bnd’s default behaviour and tells it not to add the mandatory attribute. It also includes a bunch of other rules that I have found are necessary due to other splits in the Eclipse/Equinox bundles.
I hope that helps and made some kind of sense.
Regards,
Neil
On 23 June 2014 at 20:08:41, Eric Berryman (eric.berryman@gmail.com) wrote:
Maybe I'm doing something wrong .... I'm trying to use the
maven-osgi-plugin to bundle a jar in maven and add an activator to set some
preferences. After adding to an Eclipse RCP project, I get a CNFE for the
org.eclipse.core.runtime.Plugin when the activator tries to run:
Caused by: java.lang.NoClassDefFoundError: org/eclipse/core/runtime/Plugin
I was guessing this is an import issue, but that looks fine:
Import-Package: javax.swing,org.eclipse.core.runtime;common=split;vers
ion="3.4",org.eclipse.core.runtime.preferences;version="3.3",org.osgi.fra
mework;version="1.6"
If I use Embed-Dependency for the eclipse jars, everything works fine. Is
there something I should know about Eclipse dependencies?
Also, I used eclipse:to-maven to make a maven repo of all Eclipse 3.7.2
RCP/RAP, and this is where my eclipse artifacts get resolved from.
I would be grateful for any help understanding the issue here.