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
