Some more information to my last mail: I could imagine this automatically work in the following way:
- When we register a service via BundleContext it automatically writes the version in as a service property based on the version it finds in the MANIFEST header of the bundle that registers the service (that is the version normally that was used at compile time) - When a service is queried via the BundleContext if the version is not provided manually the version ranges appended automatically based on the package version of the interface in the MANIFEST of the bundle that queries the service Regards, Balazs Zsoldos Software Architect Mobile: +36-70/594-92-34 Everit Kft. https://www.everit.biz ---------- Forwarded message ---------- From: Balázs Zsoldos <[email protected]> Date: Wed, May 9, 2012 at 9:11 AM Subject: Re: [osgi-dev] OSGI cmpn and enterprise jars To: OSGi Developer Mail List <[email protected]> Hi, I might have missed it. I am sorry but I did not have time to go through all of the specifications till now. However I write here an example: There is an API interface in a package that has the version 2.1.0. Let's call it CACHE. We have this in the OSGI container. Based on our private rules there cannot be the same package with 2.x version 2.x as it would cause problems (developers would not free to drop bundles again and again during development). We interface is provided twice as a service in the container. The first implementation uses InfiniSpan, the Second EhCache. The EhCache implementation implements version 2.1.0 of the CACHE API, the Infinispan implementation implements version 2.0.5 (some of the functions not implemented). Now a new bundle comes that was compiled with 2.0.8. It will look for the service version (and not package) [2.0.8, 3). The numbers here mean that the service should implement the API package in this version range as at compile time that API package version was used. Till now I could not find a standard way for this. I can imagine having this method manually like this: In the implementation bundle when I register the service I give the version of package I used from the API as a service property. When I use the service I give a filter like this: (&(objectClass=APi)(&(apiversion>=2.0.8)(apiVersion<3))) Well, the question is a bit more complicated when a service is registered with multiple interfaces from different packages :). Regards, Balazs Zsoldos Software Architect Mobile: +36-70/594-92-34 Everit Kft. https://www.everit.biz On Wed, May 9, 2012 at 7:04 AM, Neil Bartlett <[email protected]> wrote: > Hello Balázs, > > With regard to service versioning, OSGi does already do this, pretty much > exactly as you have described. But you seem to be saying that this is > missing. Could you clarify please? > > Regards, > Neil > > Balázs Zsoldos <[email protected]> > 9 May 2012 00:31 > Hi, > > first of all, I am sorry I made such an argument on this mail list with my > first mail :). I feel really happy that others take serious questions that > came into my mind! > > We talked about this issue with my colleague and we made some conclusions > a couple of days ago. I may be useful for you as well what we talked about. > At our projects we would like to follow the following rules however I would > be very happy if you have any modification how to change our rules: > > - An API bundle should never expose services. That is the > implementation that register services with the interfaces of the API > - Two implementation bundles should communicate only via the API and > services > - When a project comes out from incubation the API should rarely change > - Any JAR should contain packages only that has the same releasing > lifecycle. This is true for the API packages in the same technology as > well. If there is a part that more often changes then we have to think if > they really should be in the same bundle or they have a hierarchical > connection. > - Inside one major version the API should be always backward compatible > - Inside one OSGI system there should be only one API bundle from with > the same major version > - There may be different implementation bundles that expose services > from the same API with different service properties > > What we were missing: > > - It would be useful if services had the same kind of versioning as > the API packages. The reason: > - Imagine that there is an API with version 2.2.5. This means that > implementations may come from version 2.0.0. > - If an implementation is older than an API it does not necessarily > implement all of the functions of an interface > - When someone needs a service and compilation is made with version > 2.1.2 of API bundle it can say that it needs service version [2.1.2,3). > This means that the implementation of the service has to implement this > API > version range. > > Well this may seemed to be a bit off topic but I am not sure it was. The > way how packages taken together inside one bundle is an amazingly important > thing. There should be (there might be already) how versions of API and > packages should be handled together. Well, based on our logic there should > be as many bundles as many technologies are supported in compendium and > enterprise. E.g. there should be org.osgi.services.jdbc and there should be > org.osgi.services.blueprint. The version of these parts do not have to grow > together. Well it is really sick but it came to my mind that the osgi spec > should not be one big pdf with a version but as many pdfs as many logically > different chapters are. E.g. one pdf with version for jdbc and one pdf with > version for blueprint. If all of these parts have to be released always > together it may slow down the evolution of the different parts. OSGI is > simply became too big to be handled in under one version like 4.2 or 4.3 :). > > Well I hope I could write in that way that you got my point. My problem is > that if OSGI is not separated to small bundles and specification parts in > the future with different versions and lifecycle it will lose a very > important part of modularization. It was the same with Spring. First one > big jar was made, than it was separated to many small jars when the project > got big. > > I would like to suggest also the following points: > > - There should be one OSGI certified maven repository where one java > package with one major version is allowed only in with one groupId and > artifactId. It is really annoying for example that some API-s may exist > with many different variations and everyone use them with different > groupId:artifactId pairs > - Never say that some API packages comes from one groupId:artifactId > jar at compile time and the same packages should come from different > groupId:artifactId (may be handmade jars) in the runtime environment. > > A very huge time of our work is lost as there is a big mess with API jars > and packages. The strength of Java language comes from the strict > specifications and rules. It may be time to set up some new rule (like the > ones above :) ) to keep this language and OSGI the strongest. Maven created > many very strict rules after ANT and yet made life way much easier. > > Regards, > Balazs Zsoldos > Software Architect > Mobile: +36-70/594-92-34 > > Everit Kft. > https://www.everit.biz > > > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > Alan D. Cabrera <[email protected]> > 8 May 2012 23:22 > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > Holger Hoffstätte <[email protected]> > 8 May 2012 18:57 > > (one more ;) > > On 08.05.2012 17:01, BJ Hargrave wrote: > > It has always been so. See the Bundle-Description in the companion code > jars: "Interfaces and Classes for use in compiling bundles" > > Yes, fine. Does not preclude runtime use though. > > > Those packages are then supplied at runtime by the implementation > bundles (which may want to additionally decorate the exports). > > That was the actual question: where and more importantly why is this > embedding & exporting recommended, instead of simply having both consumers > and providers refer to one or more runtime-shared bundles containing only > the interfaces? I'm genuinely curious. I can see that it makes service > provider bundles self-contained (since implemented functionality is also > offered), but IMHO that seems more like an outdated concession to manual > deployment. Not sure if that's worth the additional complexity of > embedding, which seems counterintuitive for a platform that enables safe > sharing. > > I also really hope this does _not_ mean to imply that this approach should > be followed by all bundles whose implementations somehow implement > interfaces shared with other bundles, only to artificially increase their > self-containedness? Because down that path lies huge subsystem madness.. > > thanks, > Holger > _______________________________________________ > OSGi Developer Mail > [email protected]https://mail.osgi.org/mailman/listinfo/osgi-dev > > BJ Hargrave <[email protected]> > 8 May 2012 16:01 > It has always been so. See the Bundle-Description in the companion code > jars: "Interfaces and Classes for use in compiling bundles" > > The advantage is that you have a broad palate of choices at compiler time: > many packages to choose from. But then you when make your bundle, bnd will > create the bundle to only import the packages you use. Those packages are > then supplied at runtime by the implementation bundles (which may want to > additionally decorate the exports). > > -- > > *BJ Hargrave* > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the *OSGi Alliance* <http://www.osgi.org/>* > **[email protected]* <[email protected]> > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > > > > > From: Holger Hoffstätte > <[email protected]><[email protected]> > To: [email protected], > Date: 2012/05/08 10:12 > Subject: Re: [osgi-dev] OSGI cmpn and enterprise jars > Sent by: [email protected] > > ------------------------------ > > > > On 08.05.2012 14:53, BJ Hargrave wrote: > > These companion code jars are not really intended for runtime use. They > > are intended to compile time use. It is expected that at runtime, some > > other jar, such as the implementation jar, would export the related > package. > > This is the first time I've ever heard this line of reasoning. Why is this > "expected"? Can you please describe the advantages of this approach? > > thanks. > Holger > _______________________________________________ > 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 > Holger Hoffstätte <[email protected]> > 8 May 2012 15:07 > > This is the first time I've ever heard this line of reasoning. Why is this > "expected"? Can you please describe the advantages of this approach? > > thanks. > Holger > _______________________________________________ > 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 >
<<postbox-contact.jpg>>
<<compose-unknown-contact.jpg>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
