I guess you don't want to use bndtools as the Eclipse support instead of PDE? bnd has a gradle plugin which provides offline build fidelity with bndtools in eclipse. In fact we use this bnd gradle plugin to build bnd and bndtools while using bndtools in Eclipse to develop bnd and bndtools.
bnd is the non-UI engine and bndtools is the Eclipse UI layer around bnd. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Felix Natter <[email protected]> To: [email protected] Date: 2015/01/16 17:21 Subject: [osgi-dev] Common third-party dependencies exported for usage in other bundles Sent by: [email protected] hi, I am in the process of creating a gradle build system for the Freeplane project. The (OSGi-)structure is simple: - the 'freeplane' (core) project (OSGi plugin) contains core code as well as dependencies like commons-lang, commons-io, flamingo etc. - the plugin projects ('freeplane_plugin_latex', 'freeplane_plugin_script', ...) make use of some core classes *and* third-party dependencies like commons-lang, commons-io, flamingo, ... In order not to duplicate third-party-deps in all plugins [1], the old ant code used to Require-Bundle: the core project in all plugin projects. Since Require-Bundle: is not recommended practice any more, we decided to Export-Package: the third-party-deps in the core project and Import-Package: them in the plugin projects: // core project MANIFEST Export-Package: [...] org.pushingpixels.flamingo.api.common, org.pushingpixels.flamingo.api.common.icon, org.pushingpixels.flamingo.api.common.model, org.pushingpixels.flamingo.api.common.popup, org.pushingpixels.flamingo.api.ribbon // plugin project MANIFEST Import-Package: [...] org.pushingpixels.flamingo.api.common, org.pushingpixels.flamingo.api.common.icon, org.pushingpixels.flamingo.api.common.model, org.pushingpixels.flamingo.api.common.popup, org.pushingpixels.flamingo.api.ribbon When we build Freeplane using gradle outside of eclipse, this works when bypassing 'bnd' (a tool that helps generating OSGi MANIFESTs), details are in [2]. However, when building/starting from Eclipse (Eclipse for RCP and RAP Developers), Eclipse does not allow me to Export-Package: i.e. org.pushingpixels.flamingo.api.common.* (probably because it's from a third-party jar and not built from the source of the project). It does work anyway, since the plugin projects have an eclipse project dependency on the core project BUT this would require us to modify the MANIFESTs: - when starting outside eclipse, we need the Export-Package:/Import-Package: solution (because the local third-party dependencies are not pulled transitively, see [2]) - when starting from eclipse, errors are generated for Export-Package: for third-party-deps (see flamingo above) => What is the best practice here? Do I really have to duplicate the third-party deps or is there a way to make eclipse ignore or even honor the Export-Package:? The current deployed structure of Freeplane looks like: ./core/org.freeplane.core ./core/org.freeplane.core/lib ./core/org.freeplane.core/lib/substance-7.2.1.jar ./core/org.freeplane.core/lib/flamingo-7.2.1.jar ./core/org.freeplane.core/lib/substance-swingx-7.2.1.jar ./core/org.freeplane.core/lib/swingx-action-1.6.3.jar ./core/org.freeplane.core/lib/commons-io-2.4.jar [...] ./core/org.freeplane.core/META-INF ./core/org.freeplane.core/META-INF/MANIFEST.MF [...] ./plugins ./plugins/org.freeplane.plugin.latex ./plugins/org.freeplane.plugin.latex/lib ./plugins/org.freeplane.plugin.latex/lib/plugin-1.4.1.jar ./plugins/org.freeplane.plugin.latex/lib/jlatexmath-1.0.2.jar ./plugins/org.freeplane.plugin.latex/META-INF ./plugins/org.freeplane.plugin.latex/META-INF/MANIFEST.MF [...] ./plugins/org.freeplane.plugin.openmaps ./plugins/org.freeplane.plugin.openmaps/lib ./plugins/org.freeplane.plugin.openmaps/lib/plugin-1.4.1.jar ./plugins/org.freeplane.plugin.openmaps/lib/JMapViewer.jar ./plugins/org.freeplane.plugin.openmaps/lib/JMapViewer_src.jar ./plugins/org.freeplane.plugin.openmaps/META-INF ./plugins/org.freeplane.plugin.openmaps/META-INF/MANIFEST.MF [...] Unfortunately the gradle folks didn't answer [2] :-/ [1] That would be bad for the distribution size and to some extent for the Freeplane Linux packages (we'd have to filter duplicate jars manually - the non-transitive solution seems much cleaner to me). [2] http://forums.gradle.org/gradle/topics/gradle-osgi-question-export-local-third-party-dependencies Thanks a lot in Advance! -- Felix Natter _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
