Eclipse Community Forums: Equinox » Resolving Ambiguity for Import-Package

Home » Eclipse Projects » Equinox » Resolving Ambiguity for Import-Package

Resolving Ambiguity for Import-Package [message #114785]

Mon, 21 July 2008 03:30

Eclipse User

Originally posted by: goetz.jexam.gmail.com

Hi,
if one has a bundle in version 2 and clients written against version 1 auf
this bundle one needs to provide an adapter. This adapter needs to look
like bundle version 1 and delegate calls to version 2.
The problem is, that usually version 1 and 2 have classes which names were
not changed between the versions and hence are called equaly. Using
Import-Package or Required-Bundle doesn't work, because of this ambiguity.
Is there a solution for resolving ambiguity, yet ?

Regards
Sebastian

Re: Resolving Ambiguity for Import-Package [message #114866 is a reply to message #114785]

Mon, 21 July 2008 11:58

Eclipse User

Sebastian Götz schrieb:
> Import-Package or Required-Bundle doesn't work, because of this ambiguity.
> Is there a solution for resolving ambiguity, yet ?

You can specify a version together with Export-Package. Then, on
Import-Package you can specify a required version range.

-Gunnar

--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/

Re: Resolving Ambiguity for Import-Package [message #115174 is a reply to message #114866]

Thu, 24 July 2008 04:18

Eclipse User

Originally posted by: goetz.jexam.gmail.com

Thanks for your answer. Unfortunately it doesn't work for my purpose.
I've got 3 bundles: A, B and C.

I have a framework in two versions. The newer version is encapsulated by
bundle C. Bundle B consists of adapters, which provide the same structure
as the older version of the framework. These adapters shall point to their
corresponding classes in bundle C.
Bundle A contains a client application written against the old version of
the framework and hence shall link against Bundle B. So the configuration
looks like this: A->B->C.
The problem is, that some classes in B and C have the same fully qualified
name, A shall use B's version of those classes and B shall use C's version
of these classes.
If i export the classes in C using some version number, import them into B
and export B's classes for import into A, than A will see C's classes and
not B's. For me it looks like the import version 2+export version 1 in
bundle B propagates version 2, because those classes defined in B are
overwritten by the imported ones.

Is there any solution for this ?
If not, which project should I take as a starting point to enhance the
current equinox implementation in order to provide a solution for this
problem?

Re: Resolving Ambiguity for Import-Package [message #115202 is a reply to message #115174]

Thu, 24 July 2008 11:52

Eclipse User

Sebastian Götz schrieb:
> Is there any solution for this ?

Have a look at this thread:
http://www.mail-archive.com/osgi-dev@bundles.osgi.org/msg000 61.html

It may not be possible. Can you redesign the package layout in v2 (C)?

-Gunnar

--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/

Re: Resolving Ambiguity for Import-Package [message #115215 is a reply to message #115202]

Thu, 24 July 2008 12:06

Eclipse User

Originally posted by: goetz.jexam.gmail.com

Gunnar Wagenknecht wrote:

> Have a look at this thread:
> http://www.mail-archive.com/osgi-dev@bundles.osgi.org/msg000 61.html

This link is broken (404).

> It may not be possible. Can you redesign the package layout in v2 (C)?

No. The package layout/the fully qualified names of all classes must not
be changed. Both client and v2 of the framework shall stay untouched. Only
the adapter bundle representing v1 can be changed (as long as the client
still links against it, thus no structural changes are allowed).

Regards
Sebastian

Re: Resolving Ambiguity for Import-Package [message #115251 is a reply to message #115215]

Fri, 25 July 2008 02:42

Eclipse User

Sebastian Götz schrieb:
>> Have a look at this thread:
>> http://www.mail-archive.com/osgi-dev@bundles.osgi.org/msg000 61.html
>
> This link is broken (404).

Hmm. Works fine here.

This are the post details:
[osgi-dev] split package version numbers
Jeff McAffer
Fri, 31 Mar 2006 06:09:19 -0800

Maybe you can find the thread here:
https://mail.osgi.org/mailman/listinfo/osgi-dev

-Gunnar

--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/

Re: Resolving Ambiguity for Import-Package [message #115278 is a reply to message #115251]

Fri, 25 July 2008 03:44

Eclipse User

Originally posted by: goetz.jexam.gmail.com

Gunnar Wagenknecht wrote:

> This are the post details:
> [osgi-dev] split package version numbers
> Jeff McAffer
> Fri, 31 Mar 2006 06:09:19 -0800

Thanks, i found it. Unfortunately the split package approach doesn't solve
my problem, as i don't have a package of which different parts shall
evolve separately. Though it allows to provide different versions of the
same package from different bundles, it requires to split the original
package into multiple subpackages. Or am I wrong ?

Regards
Sebastian

Re: Resolving Ambiguity for Import-Package [message #115304 is a reply to message #115278]

Fri, 25 July 2008 05:21

Eclipse User

Sebastian Götz schrieb:
> Thanks, i found it. Unfortunately the split package approach doesn't solve
> my problem, as i don't have a package of which different parts shall
> evolve separately.

Uhh? I thought this is what we are discussing here.

Bundle A:
Import-Package: my.api;version="[1.0.0,2.0.0)"

Bundle B:
Require-Bundle: C;bundle-version="2.0.0"
Export-Package: my.api;version="1.0.0"

Bundle C:
Export-Package: my.api;version="2.0.0"

No?

> Though it allows to provide different versions of the
> same package from different bundles, it requires to split the original
> package into multiple subpackages. Or am I wrong ?

Split package allows to have multiple bundles exporting different
"parts" of the same package. Eclipse has been using this since
org.eclipse.core.runtime was split up into multiple bundles. All bundles
provide some part of the org.eclipse.core.runtime package. However, as
stated in the thread, the versions cannot differ.

-Gunnar

--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/

Re: Resolving Ambiguity for Import-Package [message #115329 is a reply to message #115304]

Fri, 25 July 2008 06:03

Eclipse User

Originally posted by: goetz.jexam.gmail.com

Gunnar Wagenknecht wrote:

> Bundle A:
> Import-Package: my.api;version="[1.0.0,2.0.0)"

Import-Package: my.api;version="1.0.0"

> Bundle B:
> Require-Bundle: C;bundle-version="2.0.0"
> Export-Package: my.api;version="1.0.0"

> Bundle C:
> Export-Package: my.api;version="2.0.0"

> No?

The problem is, that there are no different parts, the whole package is to
be exported/imported in different versions. Bundle B contains package
my.api itself. Bundle A shall import only classes defined in this package
of Bundle B. Bundle C too contains this package, but in another version. A
shall not see the package from C, but B shall see the package of C. For
Example class my.api.C1 defined in B shall have a delegation field to
my.api.C1 defined in C.
Its solvable using reflection, but i hoped, that OSGi provides direct
support for this.

Who can I ask where to start getting familiar with the equinox sources,
especially regarding the classloading/bundle dependency resolution?

Regards
Sebastian

Previous Topic:	How to telnet to osgi console when use server-side equinox?
Next Topic:	Question regarding ServiceSelector Filter mechanism

Goto Forum:

-=] Back to Top [=-

Current Time: Sun May 11 22:28:39 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter