On 08/02/2008, Marshall Schor <[EMAIL PROTECTED]> wrote:
>
> I am converting an older Eclipse plugin (pre Eclipse 3.2) to build with
> maven-bundle-plugin.
>
> When I run the bundle:bundle goal, it generates an Import-Package that
> includes:
> org.eclipse.core.runtime;common=split.
Hi Marshall,
Could you post a copy of your pom? (or send it to me via my personal email)
BTW, do you have any Eclipse plug-ins as compile/default scope dependencies?
If so, then try changing them to be provided dependencies, as you expect
them
to be provided by the Eclipse framework - compile dependencies are really
only
needed if you want to embed classes from other plug-ins inside the final
bundle.
For example, if you only want to depend on JFaces (ie. not embed any of it):
<dependency>
<groupId>org.eclipse.jface</groupId>
<artifactId>org.eclipse.jface</artifactId>
<version>3.3.0</version>
<scope>provided</scope>
</dependency>
BND scans compile scope dependencies for any exported version information
or mandatory attributes relating to the bundle's imported packages. Provided
scope dependencies are not scanned, so you shouldn't then see the attribute.
The reason BND adds it for compile dependencies is to ensure the bundle is
compatible with the various parts it was composed from - hence it copies the
common attribute (which is used to tell the OSGi framework how to assemble
split packages from various bundles).
The inclusion of the "common=split" causes the build to include just a
> piece of the org.eclipse.core runtime; the build then fails because my
> older plugin is using methods that are now marked as "forbidden". The
> exact messages look like:
> Access restriction: The xxx is not accessible due to restriction on the
> required library. One post says this message can also come from the
> method not being there.
>
> If I manually edit the generated MANIFEST.MF and remove the
> ";common=split", these errors citing forbidden access restrictions go
> away.
Yes, as you only import this package, you shouldn't need this attribute.
According to
> http://osdir.com/ml/ide.eclipse.equinox.devel/2006-04/msg00009.html
> using the import without the ;common=split includes all the former parts
> of the org.eclipse.core.runtime. See also
>
> http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/runtime_components.htm
>
> I suspect this would work fine on Eclipse 3.1 (before the refactoring
> took place that generated the common=split). Now that I'm building on
> 3.3, but want my plugin to still work with the older version of Eclipse,
> how do I do this?
Try using <scope>provided</scope> for bundle/plug-in dependencies.
HTH
I'm not an OSGi expert- so I may have misunderstood some things here -
> feel free to correct things :-)
>
> -Marshall Schor
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Cheers, Stuart
