Stuart McCulloch wrote:
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>
Yes, my POM section for this looks like:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<manifestLocation>META-INF</manifestLocation>
<instructions>
I didn't have a <version> but my local repository shows
org/apache/felix/maven-bundle-plugin/1.2.0 etc.
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)
I did this by configuring the eclipse:eclipse plugin, instead, using
<pde>true</pde> - it worked before. My config in the POM for this is:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-eclipse-plugin</artifactId>
<version>2.4</version>
<configuration>
<manifest>META-INF/MANIFEST.MF</manifest>
<pde>true</pde>
</configuration>
</plugin>
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
Well, I did the following checks: I looked at the date of the file - it
seems it has been written by the bundle plugin because everytime I run
that, the date on the file (as viewed via Eclipse's file/properties)
seems to be correct. I don't think it has been overwritten.
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
OK - I did this just now. First I shut down Eclipse so there's no
possibility of overwriting from there... I looked at the generated
manifest.
The code in the first package listed under Export-Package contains
references to org.eclipse.swt.SWT, but if you look at the uses= clause,
you'll see that the package org.eclipse.swt is not there, as an
example. (Straight cut/paste from the manifest.mf follows, sorry for
the poor formating)
Export-Package: org.apache.uima.taeconfigurator.editors.ui.dialogs;use
s:="org.eclipse.core.runtime,org.eclipse.swt.custom,org.apache.uima.a
nalysis_engine,org.eclipse.jface.fieldassist,org.eclipse.ui.forms.wid
gets,org.apache.uima,org.apache.uima.taeconfigurator,org.eclipse.core
.resources,org.apache.uima.resource.metadata,org.eclipse.swt.events,o
rg.apache.uima.cas,org.apache.uima.taeconfigurator.model,org.eclipse.
swt.layout,org.apache.uima.resource,org.apache.uima.taeconfigurator.e
ditors.ui,org.apache.uima.taeconfigurator.editors,org.eclipse.swt.gra
phics,org.eclipse.swt.widgets,org.eclipse.ui.fieldassist,org.eclipse.
jface.dialogs", ...
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)
Thanks - I'll see what I can do here to make something simple. Probably
nothing simple will show the problem because I suspect some of this is
due to "oldness" of these plugins - they're pre 3.0 and are using
runtime-compatibility, a lot of "deprecated" - now things, etc.
-Marshall
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
