Thanks Stuart - that solved part of my set of issues. I had actually
omitted the <scope> parameter in a few of the <dependency> elements.
(The others were already set to "provided"). When I added those, the
common=split went away.
However, I still have some other things I'm not understanding quite.
The first is that my code always builds OK using
"mvn clean eclipse:clean package eclipse:eclipse install". By OK I mean
there are no compile errors, and I get the Build Successful message at
the end.
But, the code doesn't build in Eclipse (using project->clean) - it gets
various errors - relating to the plugin packaging not being set up right.
The errors are related to Eclipse thinking there are things missing in
the list of import packages. With a basic POM (no <Require-Bundle> and
using the default <Import-Package> elements), although maven reports
Build Successful, no compile errors, Eclipse reports project not built-
can't find ...org.eclipse.core.runtime.jobs.ISchedulingRule - it is
indirectly referenced from the required .class files
The code causing this in my source is : container.isAccessible() where
container is an instance of IContainer, which in turn is defined in the
package org.eclipse.core.resources, which is one of the <dependencies> I
have coded.
I now do the following (in Eclipse, using the Plugin Manifest editor):
add the package org.eclipse.core.runtime.jobs (the one it can't find) to
the list of imported packages, and try to compile. This time it goes a
bit farther, and says it can't find
org.eclipse.core.commands.operations.IOperationApprover - indirectly
referenced from required .class files.
I now add that to the list of imported packages, try to compile, and it
says: it can't find org.eclipse.core.runtime.content.IContentType -
indirectly referenced from required .class files. I add that, and I now
get 1000's of "Access restriction" referring to things from the
org.eclipse.swt package. So, I add that package to the list of imports
(it wasn't on the list).
In this manner, I add, incrementally, one at a time, the following
import-packages:
org.eclipse.core.runtime.jobs
org.eclipse.core.commands.operations
org.eclipse.core.runtime.content
org.eclipse.swt
org.eclipse.swt.layout
org.eclipse.jface.window
org.eclipse.jdt.ui
org.eclipse.jdt.launching
-- and now it compiles.
So - my questions -
why does Eclipse need all these additional imports in order to
compile without errors, and the maven compile step doesn't?
If these are needed, why doesn't BND include them in the uses= and
the import-packages?
What's the right way to get things to work in both Eclipse and Maven
builds, here?
By the way, a work-around I've discovered by lots of trial and error is
to add 2 bundles in a <Require-Bundle> statement to my POM:
<Require-Bundle>org.eclipse.core.runtime,org.eclipse.ui</Require-Bundle-->
Then, both the maven and Eclipse builds work. But I have no idea why
this fixes the Eclipse builds, or why BND doesn't figure out I'm using
(or something I'm referring to is using) the packages I had to add by
hand, above, structuring the manifest to import these.
Thanks for your help, it's really appreciated :-)
Marshall (who's curiosity is having him spend way more time trying to
get to the bottom of this than is probably rational... :-)
Stuart McCulloch wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
