2009/7/14 Lewis, Eric <[email protected]>
> > > <Export-Package>*</Export-Package>
> >
> >
> > FYI, when embedding dependencies use <_exportcontents> not
> > <Export-Package>
> > as explained here:
> >
> >
> > http://felix.apache.org/site/apache-felix-bundle-plugin-faq.ht
> > ml#ApacheFelixBundlePluginFAQ-WhenIembedadependencywhydoIseedu
> > plicatedcontent%3F
>
> Umm... This actually creates private packages again, which I don't want.
no, if you use the 2.0.0 bundleplugin (which is the latest stable version)
then:
<Export-Package>*</Export-Package>
will pull in all classes from your dependencies (ie. the entire project
classpath)
into the bundle - so if you do a "jar tvf" on the bundle you'll see lots of
classes
inlined into the final jar
now if you also have:
<Embed-Dependency>*</Embed-Dependency>
then you're also telling the Bnd Tool to embed each dependency jar inside
the
final jar - so basically you end up with duplicate content (inlined and
embedded)
Every package should be exported.
right, and using:
<_exportcontents>*</_exportcontents>
<Embed-Dependency>*</Embed-Dependency>
will tell the Bnd Tool to embed all dependencies and make all the packages
contained inside them public - but without then inlining any of their
contents
of course, if you're happy using inlined content then you could just use:
<Export-Package>*</Export-Package>
instead of bothering with any Embed-Dependency instructions
If I understand the feature right, it applies only if I have packages in my
> source code which match packages in my dependencies.
no, <Export-Package> applies to your entire compilation classpath not just
your local sources - however, the default <Export-Package> is calculated to
only export your local packages
> Since I don't have any source code in that project, it shouldn't matter,
> right?
>
if you use <Export-Package>*</Export-Package> with the 2.0.0 bundleplugin
you will end up inlining your entire compilation classpath, which is usually
not
what you want
> > >
> > > Now the Eclipse RCP developer is telling me that Eclipse
> > doesn't like the
> > > MANIFEST format that Felix generates... weird!
> > > Have you ever heard of such problems? (He previously
> > created the MANIFEST
> > > by hand, putting every JAR and every package in its own line)
> > >
> >
> > sometimes a refresh (F5) is needed to get Eclipse in sync with the
> > file-system, if you run the build on the command line
> > otherwise double-click on the manifest then click on the
> > MANIFEST.MF tab and
> > it should show which lines it doesn't like
> > - then post the errors here (or perhaps capture a screenshot?)
> >
> > ( PS. don't use PDE Tools -> Organize Manifests... as that
> > will definitely
> > mess things up! )
> >
>
> Well, there are 535 errors, so it would be a BIG screenshot ;-)
> There are these kinds of errors (one example for each):
>
> - Bundle 'ch.ipi.esv.client.serverlib' exporting package
> 'org.apache.commons.io.comparator' is unresolved
> - No available bundle exports package 'javax.interceptor'
> - Package 'com.google.inject.matcher' does not exist in this plug-in
> - Unsatisfied constraint: 'Import-Package: org.apache.commons.lang.math;
> version="2.4.0"'
>
it sounds like you have a large amount of packages in this one plug-in
and you're attempting to export all of them (which is kind of opposite
to the idea behind OSGi)
the problem with this export-all approach is that you basically end up
with a load of spaghetti that PDE then has to wire up, and when it gets
stuck on one part then it starts reporting lots of errors (because they're
all interconnected)
so it may be it's just one error stopping PDE from resolving the bundle
Now, I know that these packages do exist in the dependencies, so it's
> probably some kind of misconfiguration. One of the RCP developers mentioned
> that the 'uses:=' part might be the troublemaker...?
yes, PDE doesn't like excessive "uses" constraint (but there are
places where you need them to avoid potential loader problems)
it's only when you're exporting lots of inter-related packages that
the "uses" constraints becomes an issue, I've never had trouble
using them with plug-ins that export well-defined APIs
to turn it off put <_nouses>true</_nouses> in your Bnd instructions
Also, I'm generating an Eclipse PDE project as described on the Felix page,
> but really, it's a total mess.
> Only about a third of the dependencies are in the visible 'Referenced
> Libraries', about half of them use the M2_REPO environment variable, the
> rest is hard-coded as linked resource in the .project file, and of course
> all of them point to my local Maven repo instead of the project!
well that's the Eclipse plug-in for you - which is why I adapted it in
the maven-pax-plugin to try and improve the project metadata for
OSGi / plug-in projects
Do you have any idea how I could force the Eclipse plugin to do the right
> thing? I see in the example that there seems to be a plugin.xml which I
> don't have, perhaps the path configuration is in there?
>
plugin.xml is how the plug-in contributes to the Extension registry,
it doesn't really affect the operation of the maven-eclipse-plugin or
how the paths get configured
you could create an example POM over at http://www.ops4j.org
(see http://wiki.ops4j.org/display/ops4j/Committers for access
- it's as simple as signing up) - or pick another hosting site and
put the example there (or failing that just email the project zip)
that would make it easier to see what's going on and help out,
rather than trying to reconstruct it based on email fragments
Best regards,
> Eric
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
--
Cheers, Stuart
