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.
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.
(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 List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
