Thanks, I originally thought about adding the attributes manually because toolingApi has customized build that takes output of jar task and runs jarjar to create self-contained binary. The manifest updated by bnd is lost in that transformation. But using the plugin [2] and restoring manifest content seems like best way to produce expected content.
BTW: we should ask the plugin author to put it on plugins.gradle.org so I filed https://github.com/TomDmitriev/gradle-bundle-plugin/issues/20 :-) Radim On Tue, Nov 11, 2014 at 2:23 PM, Ioan Eugen Stan <stan.ieu...@gmail.com> wrote: > H, > > I think that's a good thing since you'll be able to see the > dependencies more clearly. I can help with this, coding or just > testing . My recommendation is to use bnd [1] to build the manifest. > It uses code and bytecode introspection to solve all imports/exports. > It does the right job 99% cases for me. I use gradle bundle plugin in > my projects which relies on bnd, however it's defaults are to make > packages private. > > Regards, > > [1] http://aqute.biz/Code/bnd > [2] https://github.com/TomDmitriev/gradle-bundle-plugin > > 2014-11-11 14:40 GMT+02:00 Radim Kubacki <radim.kuba...@gradleware.com>: > > Should we build our Tooling API JAR with OSGi compatible manifest? IMO > this > > would be a good thing and it can simplify bundling into OSGi > > containers/Eclipse. > > > > We would only need to add some attributes > > > > Export-Package: > > Implementation-Title: > > Implementation-Version: > > Bundle-Version: > > Bundle-Name: > > Bundle-SymbolicName: > > Import-Package: org.slf4j > > > > Note that the only direct dependency SLF4J-API is already OSGi compatible > > (and slf4j-simple too). > > > > -Radim > > > > > > -- > Ioan Eugen Stan > 0720 898 747 > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
