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
On Wed, May 9, 2012 at 12:22 AM, Alan D. Cabrera <[email protected]>wrote:
>
> On May 8, 2012, at 10:57 AM, Holger Hoffstätte wrote:
>
> > (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
>
>
> _______________________________________________
> 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
