[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [orbit-dev] Need advice on bundles exporting the same package.
|
Hi,
I'm referring purely to hamcrest 1.1, and all the libraries belong to
the same version (see http://code.google.com/p/hamcrest/ for more)
Junit uses hamcrest core 1.1, swtbot needs all the hamcrest dependencies.
I think split packages is what I'm looking for based on the description
on zx's blog
(http://code9.com/2008/08/22/tip-split-packages-and-visibility/)
I'll try split packages out and see if it gets wired correctly. Thanks
all for your answers.
-- Ketan
On 5/2/09 01:07, Thomas Watson wrote:
> Ketan Padegaonkar wrote:
>
>
> Hi,
>
> The case in point here is the hamcrest library. Hamcrest exports
> multiple libraries (jars), most of them in the org.hamcrest package.
>
> It also ships an all-in-one jar that flattens and merges all these
> libraries into one, this is what the hamcrest orbit bundle currently
> exports. Since JUnit already bundles hamcrest-core, it is logical to
> extract this and everything else out into a separate bundle.
>
> I'm looking for advice on how to deal with bundles that export the same
> org.hamcrest packages, with different classes within them. Paul Webster
> pointed me to a similar bug [1], but I'm not sure how this works. Could
> someone please throw some light on this ?
Are you dealing with split packages? Are some of the classes
in the hamcrest library bundle and some of the classes are in the
JUnit bundle or do both bundles have the complete org.hamcrest packages
but at different versions?
I have the feeling it is the second case where the hamcrest bundle has
one version of the packages and JUnit has a different version. If that
is the case then the two bundles should export the org.hamcrest packages
at the version they include.
If both bundles are exporting the exact same version of the packages
then we have a different issue. In this case you should not care if
your hamcrest package is used or the ones exported by JUnit. But it
would be nice if we did not have both bundles export the same version
of the package in the same runtime. This is one motivation for a bundle
to export and import their packages.
See
http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html
This practice is used when you want to guarantee that a certain
version of a package is available at runtime but you are willing
to use (substitute) another bundle's export of the package if it is
available and satisfies your version and attribute requirements.
We need to be careful with this approach. It really only works well
for API packages that are pure APIs and do not include lots of
implementation or the implementation behavior is well defined and
you don't care what bundle you get the implementation from. I
don't think many of the Eclipse APIs fall into this category because
we want to ensure the implementation of a particular package comes
from one of our bundles and we are not ready to accept an implementation
from another bundle for most of the org.eclipse packages.
For many of the orbit bundles it may be acceptable to have
substitutable exports if all we want is to ensure a particular
version of an API is available at runtime. But I know this is
not true even for many orbit bundles where we care about the
actual implementation of the API.
Tom.
>
> [1] - https://bugs.eclipse.org/bugs/show_bug.cgi?id=258439
>
> -- Ketan
------------------------------------------------------------------------
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev
