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
