felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Automatic generation of Import-Package statements
Date Wed, 07 Jun 2006 07:44:21 GMT
Niclas Hedhman wrote:
> On Tuesday 06 June 2006 20:07, Richard S. Hall wrote:
>   
>> Niclas Hedhman wrote:
>>     
>>> And I am still stunned by the statement that the framework will not
>>> deliver q-1.0 to my BundleC if the exporter of q-1.0 imports q, which is
>>> resolved to q-1.1 exported by someone else...
>>> Can't find it in the spec to neither confirm nor contardict it either,
>>> and Richard's reply is also vague on the point...
>>>       
>> Standard imports cannot be split, thus if a bundle both imports/exports
>> a given package and import is selected at resolve time (i.e., the bundle
>> ends up importing it from another bundle rather than using its own),
>> then it is not possible for it to ask its fragment for a class in that
>> package, since it will error after asking the exporter it is wired to if
>> the class is not found in the exported package.
>>     
>
> Sorry, does not compute;
> Let's try this with code;
>
> Bundle A
> Export-Package: org.hedhman; version=1.0
> Import-Package: org.hedhman
>
> Bundle B
> Export-Package: org.hedhman; version=1.1
>
> Bundle C
> Import-Package: org.hedhman; version="[1.0, 1.0]"
>
>
> Is everyone now saying that Bundle C can not be resolved, although there are 
> no technical reasons for that being the case??
>   

Sorry, I misread your message that I responded to originally. I read 
"framework" as "fragment", which is why I responded talking about 
fragments. My bad.

In your example above, it depends on the framework implementation. 
However, if Bundle A is resolved to the import from Bundle B, then it 
will not be possible to resolve Bundle C.

> If so, then the whole point of version ranges are practically useless, as 
> undeterministic behavior will result due to later installations of newer 
> versions.

Not really. If you follow a practice of packaging your libraries in 
separate bundles, then you don't ever have to import/export the same 
package (i.e., library bundles should only export), then you don't 
experience this issue at all.

The point of being able to import/export the same package allows the 
bundle to be able to explicitly say that it wants its export to be 
substitutable, which is import for interoperability purposes. It has 
been considered good practice in the past to package your interfaces 
inside of the bundle of your service implementation, which makes the 
need for substitutability greater. The ability in R4 to both 
import/export the same package supports this common use case.

This really has nothing to do with the value of version ranges. If you 
don't want version 1.0 to be substituted for version 1.1, then don't 
import it too.

-> richard

Mime
View raw message