BJ Hargrave <[email protected]> writes: hello BJ,
thanks for the quick reply. Are you referring to this? https://github.com/bndtools/bnd/wiki/Gradle-Plugin https://github.com/bndtools/bndtools > I guess you don't want to use bndtools as the Eclipse support instead > of PDE? That would be a lot of work (I am running gradle 1.5 and developed an almost complete solution with the normal osgi plugin), but I would certainly switch if the bnd-gradle-plugin/bndtools solution works 100% for my use case. --> Can you confirm that this is the case (please see my mail and [2])? (I somewhat doubt that since both are using 'bnd' under the hood) Thanks a lot and Best Regards, Felix > 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 office: +1 386 848 1781 > OSGi Fellow and CTO of the OSGi mobile: +1 386 848 3788 > Alliance > [email protected] > > 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 -- Felix Natter _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
