| Resolving Ambiguity for Import-Package [message #114785] |
Mon, 21 July 2008 07: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 #115174 is a reply to message #114866] |
Thu, 24 July 2008 08: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 #115215 is a reply to message #115202] |
Thu, 24 July 2008 16: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 #115278 is a reply to message #115251] |
Fri, 25 July 2008 07: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 09:21 |
|
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 10: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
|
|
|
Powered by
FUDForum. Page generated in 0.03499 seconds
] 
Search
Help
Register
Login
Home
