David Kemper wrote:
All,
I am running into a version compatibility issue that worries me.
Although I will describe this in terms of the Equinox implementation,
I think it is a general OSGi issue.
I have a utility class that combines the OSGi StartLevel service with
a service tracker so that you can simply make the start level calls to
it, and the implementation does the work of checking for and
dereferencing the service (throwing suitable exceptions on failure).
It is declared thus:
----
public class StartLevelTracker
extends ServiceTracker
implements StartLevel {
}
----
I wrote the implementation in/on Eclipse 3.2 whose underlying OSGi
framework is R4.
When I downloaded and moved to Eclipse 3.3 whose underlying OSGi
framework is R4.1, this utility class no longer compiles.
Between version 1.0 of the StartLevel service package and version 1.1,
the start level service has the new method
isBundleActivationPolicyUsed(Bundle bundle).
Of course my implementation of this interface lacks the new method and
does not compile.
The crux of my question: Doesn't the addition of a method to an
interface break backwards compatibility?
I would think this breaks forward compatibility, but maintains backwards
compatibility....
-> richard
It is my impression that the semantics of OSGi versions is that code
should be backwards-compatible through major versions. We write all
our dependencies as "[a.b.c,a+1.0.0)" e.g. "[1.2.3,2.0.0)". This
particular change appears to break backwards compatibility on that
package while only incrementing the minor version. Should we only
rely on compatibility within minor versions? If so, won't that
increase the likelihood of wiring issues across many bundles?
Or, put another way, does implementing an interface from an exported
package tie you to a very narrow version range, and if so, should this
be avoided?
Additionally, this issue is magnified when Require-Bundle is brought
in. I know that the OSGi position is that Import-Package should be
used to create loosely-coupled systems. However Eclipse continues to
provide much/most of its architecture using Require-Bundle, with more
projects springing up all the time. As an engineer developing bundles
that use third-party bundles of both philosophies, I am starting to
encounter wiring problems as our systems pass the "Hello, World"
scale...our runtimes have literally hundreds of bundles.
Thanks in advance.
/djk
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
