2009/7/15 Lewis, Eric <[email protected]> > 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? >
sure, ok with me Best regards, > Eric > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Cheers, Stuart
