I think Tom's description of the situation is slightly inaccurate (or at
least confusing to me).
In R4, if bundle A both exports and imports package foo, then bundle A
is specifically saying that it is willing to have its version of foo
substituted for a different version at resolve time. Why does bundle A
want to do this? To be interoperable with other bundles that might being
using a different version of foo. This substitutability was the default
in R3 for interoperability purposes and by and large should be the
default way to generate your metadata in R4 too.
Further, there is no direct connection between having explicit
exports/imports for a given package and the framework only allowing one
version of that package.
Even with explicit exports/imports for a given package, it is still
possible to have multiple versions of a given package because it is
possible to specify the precise versions allowed for substitutability on
the import declaration. So, this is really the improvement from R3, R4
does not impose 100% backwards compatibility. It allows the bundle to
say, "I can accept substitutability within this version range," which is
much more realistic.
However, after having said all of that. This is really only important
for bundles that export packages and actually do something with those
packages themselves, i.e., have a bundle activator. If a bundle is
purely just a library bundle that simply just exports some packages,
then it does not need to explicitly import the packages too, since this
will potentially hide its version of the packages (unless it specifies
its precise version on the import).
-> richard
Thomas Watson wrote:
Niclas Hedhman <[EMAIL PROTECTED]> wrote on 06/04/2006 03:02:34 AM:
If you always import every package you export then you will
prevent multiple versions of the same package from being available
in the system.
I don't follow this argument. IIRC, the multiple versions of the
same packages
has been with OSGi since the early days, and not anything new in R4.
For example, imagine you must support two versions
of the junit library in your system at the same time. One junit
bundle version 3.8.1 exports all of its junit packages at version
3.8.1. Another junit bundle version 4.1.0 exports all of its junit
packages at version 4.1.0. Both of these bundles can be installed
and resolved at the same time. Now if the 3.8.1 junit bundle
imports every package it exports then the resolver can resolve
its imports to the 4.1.0 versions of the junit packages. This will
drop the exported packages from the 3.8.1 version of the bundle and
make them unavailable to the rest of the bundles in the Framework.
Huh? No. That depends on the version directives.
And the way I interpret the spec (but I can have missed something) is
that;
If Bundle A exports q-1.0 and imports q, and Bundle B exports q-1.1 and
the
framework resolves A's import to B's export, A will still provide the
export
of q-1.0 for, for instance, Bundle C that imports q-1.0 (restricted).
So that albeit Bundle A doesn't use its own exported packages, it will
still
have to provide it for those who depends on them.
This is not how it works. In R3 if multiple bundles (X and Y) exported
the
same package (foo) then the framework will choose only one bundle (X) to
be
the exporter and every other bundle (Y) would import the package (foo).
This is called implicitly importing a package. A bundle can only import
OR
export a package but it cannot do both at the same time. If the framework
chooses another bundle (X) to export the package (foo) then the other
bundle (Y) becomes an importer of the package and the export of (foo)
is not available from bundle (Y).
In OSGi R4 the specification changed such that multiple bundles can offer
to export the same package. In R4 if a bundle exports a package it no
longer implicitly imports the package. If two bundles export the same
package AND do not explicitly import the package then there will be two
"versions" of that package available in the framework. But R4 still
uses the same rules if a bundle explicitly imports a package. If a bundle
imports a package and that import did not resolve to its own export of
that
package then the export is dropped from that bundle and is not available
in the framework.
This also puts a much greater burden on the developer when they
decide to export a package. If every exported package is also
imported then the developer must be prepared to handle when their
own exported package is substituted with another version of the
package from a different bundle. This means you cannot have
any internal implementation dependencies on the packages you
export.
This is an accurate note, which I "hope" the Maven plugin will detect
and
report, if not now then it should be added.
In your example manifest you have over 100 exports.
Are you prepared for any one of those exports being replaced with
a package from another bundle? Are there no internal
implementation dependencies between your packages. With such a
large set of packages it seems likely you would have some
internal implementation dependancies.
In my case, I am 'suffering' the "legacy syndrom". The majority of
packages
are "Wicket", a web framework outside the OSGi domain, which I am OSGi
enabling with dynamic components, replacable pages, and other OSGi
tricks.
Since
a) the Wicket components and pages will sit in their own bundles,
b) I want aviod limiting what you can do in Wicket,
c) Wicket was not designed for OSGi,
I have not much choice than export all their packages.
The interesting case, however, is what are the implications if Wicket is
imported from somewhere else? For the time being I have said, "not
allowed"
as I think there are still a couple of classloader issues involved, but
that
is a totally different story.
If I follow you correctly, you are stating that you are not willing to get
the wicket packages from another bundle. If that is the case then I would
suggest you not explicitly import the wicket packages. Or is this just
a temporary issue that you hope to allow for in the final version of your
bundle?
I'm picking on your particular example because of the various issues that
need to be considered while using automated tools. If the tools have
unreasonable defaults then many developers will fall into the same issues.
I think it is vitally important that a developer carefully considers every
package they import because of the ramifications of such a decision.
For example, how does the tool know what version of the package you need?
This becomes even more important if you export that package. Maybe you
export the package at version 2.1 but you can actually use version 2.0 if
it is already available on the framework. I'm not sure an automated tool
will be able to make such developer orientated decisions.
Tom
