Hi Stuart > > no, if you use the 2.0.0 bundleplugin (which is the latest > stable version)
Yes, I do. > 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) Well, I don't know if I mentioned it, but I'm doing this to create one Eclipse plugin which contains all our dependencies. Basically we're doing a client/server application, and of course the client has to know all the server objects (a couple of JARs with their dependencies) to work. We've been messing around with this topic for some time now, and there seems to be no really elegant solution. Either all dependencies have to be OSGi bundles (and good luck finding them) or you glue up some super-plugin with all the JARs in the build.properties and all the packages exported in the MANIFEST.MF Perhaps we're totally wrong with this second approach, but it a short test (done by hand) worked. However, building this with Maven and friends seems a bit more difficult. > > 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 > > > 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 > > > 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 I think your explanation is good but goes over my head ;-) As I mentioned, since we don't know better, we just want to export every package of the dependencies and their transitive dependencies. > 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) Right, but we've come to the conclusion that it's the only thing that works :-( I did discuss with the Eclipse guys that (from my newbie OSGi view), all dependencies should be OSGi bundles, and that the plugins should just pick whatever they like. But it seems that this results in classloader problems. > > 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 Yes, I'm now down to one (!) dependency (and its transitive dependencies) - still doesn't work (26 errors). > > 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 Thanks, but first I'll try the maven-pax-plugin. > > 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 I'll try that next. > > 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 Would it be ok if I send you a ZIP to your personal email address? Best regards, Eric --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
