felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Berryman <eric.berry...@gmail.com>
Subject Re: CNFE org.eclipse.core.runtime.Plugin
Date Tue, 24 Jun 2014 01:37:20 GMT
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 <njbartlett@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.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message