On 11/02/2008, Marshall Schor <[EMAIL PROTECTED]> wrote:
>
> 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.
Hi Marshall, good to hear that particular issue was solved
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
just checking - you do set <manifestLocation> in the configuration part
of the bundleplugin section (not inside the instructions) to write it to the
place that Eclipse/PDE expects it? ie:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>1.2.0</version>
<extensions>true</extensions>
<configuration>
<manifestLocation>META-INF</manifestLocation>
<instructions>
<!-- various BND instructions -->
</instructions>
</configuration>
</plugin>
as described in the bundleplugin docs (Eclipse/PDE integration section).
You also need to use the "-Declipse.pde" setting with eclipse:eclipse or
it won't create the right kind of project (ie. it won't have the PDE nature)
mvn clean package eclipse:eclipse -Declipse.pde install
then use "Import existing project" from Eclipse - as you develop you may
need to add Maven dependencies to the pom and rebuild the manifest.
You can also add packages manually to the manifest when using Eclipse
for rapid prototyping, but eventually you'll want to rebuild with Maven.
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?
it sounds like either the bundleplugin manifest has not been written
to the right place (ie. META-INF directory under the project directory)
or perhaps it has been overwritten somehow
it could also be that Bnd has missed these imports, but I doubt that if
PDE was able to find them (as that suggests they can be found via the
bytecode, which is what Bnd uses).
If these are needed, why doesn't BND include them in the uses= and
> the import-packages?
well, it should - if they are needed and Bnd has missed them it's a bug.
but it might also be that Eclipse/PDE is complaining when your bundle
would actually work in an OSGi framework (sometimes its access rules
don't quite match with the spec'd OSGi access rules)
What's the right way to get things to work in both Eclipse and Maven
> builds, here?
check the manifest location - you could also use plain "mvn clean install"
to verify the bundleplugin generated manifest is missing those packages
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
the Require-Bundle instruction will be passed straight to the manifest
and means that your bundle will automatically import any packages
exported by those required bundles (ie. no need for Import-Package)
Require-Bundle can be useful for certain legacy situations, but it also
means your bundle is tied to specific other bundles (rather than the
java packages it uses). It also means the packages that are visible
to your bundle will change whenever the required bundles change
their exports, which can make things harder to maintain.
, 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 :-)
no problem - if you can provide a simple project that demonstrates
the missing import issue I can investigate further (you can send it to
me directly to avoid spamming the list)
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]
>
>
--
Cheers, Stuart
