Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: felix-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <44854999.9070201@ungoverned.org>
Date: Tue, 06 Jun 2006 05:23:37 -0400
From: "Richard S. Hall" <heavy@ungoverned.org>
User-Agent: Thunderbird 1.5.0.2 (X11/20060501)
MIME-Version: 1.0
To: felix-dev@incubator.apache.org
Subject: Re: Automatic generation of Import-Package statements
References: 
 <OF2DB6706C.1CA6EB46-ON86257184.0046F31A-86257184.0049B0F3@us.ibm.com>
In-Reply-To: 
 <OF2DB6706C.1CA6EB46-ON86257184.0046F31A-86257184.0049B0F3@us.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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 <hedhman@gmail.com> 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
>
>
>