I forgot to mention: Basically, this is what the Eclipse developers did: http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.pde.doc.user/guide/tools/project_wizards/plugin_from_archives.htm
> -----Ursprüngliche Nachricht----- > Von: Lewis, Eric [mailto:[email protected]] > Gesendet: Mittwoch, 15. Juli 2009 13:42 > An: [email protected] > Betreff: AW: Create Eclipse plugin from all dependencies - how? > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
