On 01/01/2008, Ingo Meyer <[EMAIL PROTECTED]> wrote: > > Hi , >
Hi Ingo, first, HAPPY NEW YEAR to you all... 8-) > Happy New Year! I have the following problem since i've updated to the newest pax-construct > version 0.6.2. > > In one bundle which depends on "org.eclipse.core.runtime" - it is a > eclipse rcp application bundle - > I now get always the following import (which is wrong): > > Import-Package: org.eclipse.core.runtime;registry=split > > before it was without "registry=split"! > > Does anybody nows what is wrong? > Do you have "org.eclipse.equinox.registry" as a compile/default scope dependency? If so, then you should change it to be a provided dependency, as you expect it to be provided by the RCP container - compile dependencies are only needed if you want to embed classes from them inside the final bundle. Having org.eclipse.equinox.registry as a compile dependency means that BND will scan it for any exported version information or mandatory attributes relating to the bundle's imported packages (provided scope dependencies are not scanned). This is where "registry=split" comes from, because the registry bundle exports the package as follows: org.eclipse.core.runtime ;registry="split";mandatory:="registry" Hence BND adds the mandatory attribute, to match the export it found. The reason the registry bundle uses a mandatory attribute is to get around a split package issue, ie. two bundles export different classes in the same package space - and this shows why split packages are bad, because it quickly gets very confusing! ( The org.eclipse.core.runtime bundle exports the package without any attributes ) So to sum up - change to use provided scope for bundle dependencies... HTH Note: I think the reason you only saw this recently was because in moving to the new Pax-Construct, you also moved to the latest bundleplugin which has a later version of the BND tool (earlier versions did not augment mandatory attributes). Thanks > Ingo > > _______________________________________________ > general mailing list > general@lists.ops4j.org > http://lists.ops4j.org/mailman/listinfo/general > > -- Cheers, Stuart
_______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
