Hi all, Thanks for the feedback.
Probably, I will not include the service.log package as I will the service.cm package. Regarding the log package, scr is really only a client, that is, it uses the LogService class (and not more) of that package. We could of course document, that scr only exports the service.log package to have it handy for logging, but actually, I do not particularly like exporting interfaces from a bundle, which does not provide an implementation (and which does not "define" the service for a third party to implement). SCR is simply a client of the log service. As for the cm package, the situation is more complicated as scr has an implementation of an interface in the cm package (namely ManagedServiceFactory). So, in fact inclusion in case of ConfigAdmin absence is probably a must. Regards Felix On 5/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>Richard S. Hall a écrit : >> Clement Escoffier wrote: >>> Hello >>> >>> Felix Meschberger a écrit : >>>> Hi Richard, >>>> >>>> In Felix-277 you propose to "privatize" the ServiceTracker and make the >>>> LogService package a dynamic dependency. I think, this is a good >>>> idea and >>>> will, as noted in the issue, implement this. >>>> >>>> While doing this, there is another Compendium Service dependency in >>>> the scr: >>>> Configuration Admin Service. This is a more complicated dependency >>>> because >>>> scr does not only call into the ConfigurationAdmin service but also >>>> registers a ManagedServiceFactory for factory components. So, if the >>>> OSGi cm >>>> packages are not available, factory components will not work (and >>>> configuration retrieval by other components may fail). >>>> >>>> What do you think of having scr export and re-import the OSGi cm >>>> package ? >>>> This way, the framework would select the cm package to which other >>>> bundles >>>> get wired and scr will have the OSGi cm packages regardless of >>>> whether a CM >>>> implementation exporting it is available. >>> It is what I do for the Log service and the Config Admin in iPOJO. It >>> increase the size of the bundle but I did not find another acceptable >>> solution. >>> The pom file contains folowing BND instructions: >>> <Import-Package> >>> org.osgi.framework; version="1.3", >>> org.osgi.service.cm; version="1.2", >>> org.osgi.service.log; version="1.3" >>> </Import-Package> >>> <Export-Package> >>> org.apache.felix.ipojo; version="0.7.1", >>> ....... (some other iPOJO packages) ..... >>> org.osgi.service.cm; version="1.2", >>> org.osgi.service.log; version="1.3" >>> </Export-Package> >> >> Shouldn't BND automatically detect the versions for you from the >> packageinfo files? >BND inserts versions for imported (and re-exported version), but does >not add version for non imported packages (In the previous snippet, BND >can add 1.3 and 1.2 version but cannot discover 0.7.1 version). Well, you could add a packageinfo file to your iPOJO directories too, then BND will automatically "discover" the version of iPOJO packages too as far as I understand it. But at a minimum, you can simplify your pom by removing the versions from the cm and log packages, since they do have packageinfo files, so they should be detected properly. -> richard
