Hi, thank you again for the detailed answer.
I don't think there is any justification for blessing either of these as a "Best Practice", since it depends on your use cases. I must disagree. I think if developers get free hand in situations like this it will really hit back in a longer period. Now as OSGI is imported into all major Java EE application servers OSGI is just before a big explosion (similarly when suddenly many projects went from ANT to Maven as a compilation tool). More specifically the explosion has already been started. Without strict rules in this questions and building up dependency management repositories (like maven or P2 update sites) based on these rules will make developers suffer (working at night to find out what went wrong) a lot in the future. The purest way should be chosen and the one that makes the highest concistency between the bundles. Well in my opinion it means a little bit more work and more separate jars as you already know :). Regards, Balazs Zsoldos Software Architect Mobile: +36-70/594-92-34 Everit Kft. https://www.everit.biz On Wed, May 9, 2012 at 11:05 AM, Neil Bartlett <[email protected]> wrote: > Sorry for the partial message, I am having some connectivity problems. > Full intended message is as follow: > > There are advantages and disadvantages to both approaches, i.e. including > service APIs in the provider bundle versus separating them into "pure" API > bundles. Each involves trade-offs, and even experts disagree on which set > of trade-offs is best (or rather, least-bad) in various scenarios -- as > shown by the email exchange between Holger and BJ on this thread. > > The advantage of bundling APIs inside provider bundles is that it allows > the provider to be self-contained, i.e. it does not need any other bundles > present in order to work. The disadvantage is that dynamically updating the > provider bundle becomes harder, because client will not see the new service > from the update until they are refreshed. Note that in addition to > exporting the API, the provider should always import the API as well, so > that it can still import it from a pure-API bundle if one is present. > > You're already clear on the advantages of pure-API bundles, but the > disadvantage is that you must always have the API bundle present in order > for the provider to resolve. This may create an additional management > burden since you need two bundles instead of one... however as Holger > points out, dependency management tools based on, say, OBR repositories can > largely eliminate this burden. > > I don't think there is any justification for blessing either of these as a > "Best Practice", since it depends on your use cases. > > Neil > > On Wed, May 9, 2012 at 9:42 AM, Neil Bartlett <[email protected]>wrote: > >> There are advantages and disadvantages with both approaches, i.e. >> including service APIs in the provider bundle versus separating them into >> "pure" API bundles. Each approach involves trade-offs, and as a result even >> experts can disagree on which set of trade-offs is best (or rather, >> least-bad) in various scenarios -- as shown in the email exchange between >> Holger and BJ on this thread. >> >> The advantage of bundling APIs inside provider bundles is that it allows >> the provider to be self-contained, i.e. it does not need any other bundles >> present in order to work. The disadvantage is that dynamically updating the >> provider bundle becomes harder, because client will not see the new service >> from the update until they are refreshed. Note that in addition to >> exporting the API, the provider should always import the API as well, so >> that it can still import it from a pure-API bundle if one is present. >> >> You're already clear on the adv >> >> Balázs Zsoldos <[email protected]> >> 9 May 2012 09:31 >> Hi, >> >> thank you very much for the information. I did not know that this >> automatism works behind already. I was suspecting not because in OSGI 4.2 >> we define service interfaces with only strings. I was wrong than. >> >> In this case one problem is solved already :). The other one with the >> osgi-enterprise and osgi-compendium makes still question marks in my head. >> In my opinion an implementation bundle should never contain utility classes >> or API that other bundles may use. Also I have this feeling that one major >> versioned API should be allowed only ones in one OSGI container (or >> subsystem or something that means an application scope). Also I still think >> that each logically separated API should have a dedicated bundle and >> implementors should not take these API packages into their bundles... >> >> Thanks for the patiente and especially for your last mail! >> >> 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 >> Neil Bartlett <[email protected]> >> 9 May 2012 08:42 >> Balázs, >> >> This is not really the right way to version services. Service >> compatibility is based on the versioning of package exports and imports. >> >> For example, if your provider bundle implements version 2.0.x of the API >> then it should use an Import-Package range of [2.0,2.1). This is because a >> bump in the minor version (second segment) is meant to indicate a new >> feature, and therefore would break providers as you noted. >> >> If a client bundle understands version 2.0.x of the API then it should >> import the package with a range of [2.0,3). This is because clients do not >> care about additional features, they only care about true >> backwards-incompatible breaks, which are indicated by a bump of the major >> version. >> >> At runtime, the service registry will only permit the client bundle to >> see services published by a provider that is bound to the same exported >> package. Therefore it is unnecessary to layer your own arbitrary versioning >> information on top of this. >> >> I strongly encourage you to read some documentation in this area -- >> either the specification itself or "OSGi in Action" by Richard Hall et al >> -- before proceeding. This will help you to avoid inadvertently reinventing >> mechanisms that already exist. >> >> Regards, >> Neil >> >> Balázs Zsoldos <[email protected]> >> 9 May 2012 08:11 >> 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 >> >> >> >> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> Neil Bartlett <[email protected]> >> 9 May 2012 06:04 >> 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 >> >> > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
<<compose-unknown-contact.jpg>>
<<postbox-contact.jpg>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
