The embedding was done for pre R5 as there was no guarantee that the framework actually provided it. So for R5+ implementations, it could be removed
Carsten 2014-09-09 19:19 GMT+02:00 Neil Bartlett <[email protected]>: > Hi Christiano, > > I apologise, my information was out of date. Tracker used to be a non-core > package, apparently it moved to core in R5. > > Still, since it doesn’t form a contractual API between the framework and a > bundle, it’s safe to embed a private copy… though completely unnecessary > since R5! > > Neil > > On 9 September 2014 at 18:06:15, Cristiano Gavião ([email protected]) > wrote: > > Hi Neil, > > thanks for the clarification, but I didn't understand your latest > sentence... what do you mean about > > Note that the tracker package is not and has never been part of OSGi > > Core. ? > > Below is part of the manifest of osgi.core 6 (5 too) and tracker package > is being exported there... > > Export-Package: > org.osgi.dto;version="1.0", > org.osgi.resource;version="1.0", > > org.osgi.resource.dto;version="1.0";uses:="org.osgi.dto",org.osgi.framework;version="1.8", > org.osgi.framework.dto;version="1.8";uses:="org.osgi.dto", > org.osgi.framework.hooks.bundle;version="1.1";uses:="org.osgi.framework", > > org.osgi.framework.hooks.resolver;version="1.0";uses:="org.osgi.framework.wiring", > org.osgi.framework.hooks.service;version="1.1";uses:="org.osgi.framework", > > org.osgi.framework.hooks.weaving;version="1.1";uses:="org.osgi.framework.wiring", > org.osgi.framework.launch;version="1.2";uses:="org.osgi.framework", > org.osgi.framework.namespace;version="1.1"uses:="org.osgi.resource", > org.osgi.framework.startlevel;version="1.0";uses:="org.osgi.framework", > org.osgi.framework.startlevel.dto;version="1.0";uses:="org.osgi.dto", > > org.osgi.framework.wiring;version="1.2";uses:="org.osgi.framework,org.osgi.resource", > > org.osgi.framework.wiring.dto;version="1.2";uses:="org.osgi.dto,org.osgi.resource.dto", > > org.osgi.service.condpermadmin;version="1.1.1";uses:="org.osgi.framework,org.osgi.service.permissionadmin", > org.osgi.service.packageadmin;version="1.2";uses:="org.osgi.framework", > org.osgi.service.permissionadmin;version="1.2", > org.osgi.service.startlevel;version="1.1";uses:="org.osgi.framework", > org.osgi.service.url;version="1.0", > *org.osgi.util.tracker;version="1.5.1";uses:="org.osgi.framework"* > > On 09-09-2014 13:28, Neil Bartlett wrote: > > It’s unusual to see this package embedded, because it’s almost > > guaranteed to be available from the framework exports. However it’s > > not really a problem either, since trackers are an internal > > implementation detail. > > > > The packages that should never be embedded (at least not privately) > > are those that form a contract between you and another bundle — e.g. > > service APIs — or are part of the core contract between a bundle and > > the OSGi Framework, such as the OSGi core packages including things > > like ServiceReference, BundleContext, BundleActivator etc. > > > > Note that the tracker package is not and has never been part of OSGi > Core. > > > > Regards > > Neil > > > > On 9 September 2014 at 15:08:35, Cristiano Gavião ([email protected] > > <mailto:[email protected]>) wrote: > > > >> Hi all, > >> > >> I'm facing a class duplicity problem and while investigating it I noted > >> that org.apache.felix.configadmin, org.apache.felix.scr and others > >> embeds the /org.osgi.util.tracker/ package inline in its own bundle. > >> > >> I thought that this package would be imported/used from the framework... > >> > >> What is the reason for such approach ? when should I worry to embed > >> packages from osgi.core in my own bundle ? > >> > >> many thanks, > >> > >> regards, > >> > >> Cristiano > > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
