Neil Bartlett wrote: > Craig, > > Can you describe in more detail your use-cases for versioning of > services, and why you feel they are not well supported at present? > > A service is versioned according to the exported package containing > its interface. If you have services published under the > org.example.api.IService interface, then you can version them by > exporting different versions of the org.example.api package from > different bundles. This allows for API evolution to occur while > ensuring that clients get objects that are compatible with their > expectations. There is no need to add versioning to service instances > because clients should not be aware of the implementation class. > > Regards, > Neil > > > On Wed, Dec 30, 2009 at 3:12 PM, Craig Phillips > <[email protected]> wrote: >> I also separate API from IMPL, something I don't see happening officially; >> Meaning, API bundles are their own separate entity with no service(s) >> exposed; Speaking of which, where is versioning of services? I end up having >> to put a version moniker in the service name to cover for this deficiency in >> the spec [...]
I cannot speak for Craig, but it sounds like he has the same issue I ran across: deploying an updated service implementation bundle using the same API bundle in the case where the API does not change. Once it was pointed out to me, the reason for not having a "version" on a service made sense. I eventually decided to encode the implementation bundle's minor and micro version numbers in the service ranking to avoid having to set the ranking manually and to enforce a preference for the updated service. -- Tommy M. McGuire [email protected] _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
