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
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
[email protected]
|
office: +1 386 848 1781
mobile: +1 386 848 3788
|
From:
Holger Hoffstätte
<[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
