Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] Re-exporting dependency tofragment-provided third-party API

I agree with Martin.  Import/Export-Package is the way to go.  Require-Bundle introduces brittle dependencies on specific bundles.  Re-exporting takes that brittleness to a new evil level by making your brittle dependencies the brittle dependencies of your clients using your API.  The uses directive on your exports for the third-party packages your import is the correct thing to do.  PDE can calculate this for you.  Other build tools that do code first instead of manifest first (like bnd) also will calculate your uses directives for you.

Tom





From:        Martin Lippert <mlippert@xxxxxxxxx>
To:        "eclipse.org-architecture-council" <eclipse.org-architecture-council@xxxxxxxxxxx>
Date:        04/17/2016 07:52 AM
Subject:        Re: [eclipse.org-architecture-council] Re-exporting dependency to        fragment-provided third-party API
Sent by:        eclipse.org-architecture-council-bounces@xxxxxxxxxxx




Hey Alexander,

I think using a third-party dependency in your API doesn’t mean you have to use Require-Bundle and re-export those third-party dependencies. I actually think that this would be a bad and dangerous thing to do.

I would continue to use Import/Export-Package and define use constraints on the exported packages. That way the OSGi runtime ensures that bundles that import your package and imports the third-party dependency get wired to the same third-party bundle. That way you don’t have to worry about those bundles being wired to different versions of the third-party lib.

Hope this helps!
-Martin





> Am 17.04.2016 um 11:49 schrieb Alexander Nyßen <nyssen@xxxxxxxxx>:
>
> Hi,
>
> I am currently working on opening up the provisional API of GEF4 and I ran into a case where I need some (architectural) advice.
>
> We had not exposed any public API so far (all packages were exported with x-friends or x-internal declaratives), and we did thus not re-export any third-party dependencies either. We tried to depend on Orbit bundles (Google Guice, Google Guava) via version-constrained package-imports alone. As we now open up all our API, we have to introduce re-exports for those third-party dependencies that are exposed through our own API, which requires transferring the affected Orbit package-imports into require-bundles.
>
> While this is pretty much straightforward in most cases, there is one case that bothers me: we expose com.google.inject.multibindings.MapBinder, which is provided by an Orbit fragment (com.google.inject.multibindings), not by an Orbit bundle. I can thus not transform the related package-import into a require-bundle, and I do not see a chance to properly re-export this dependency either. Is there a recommendation on how to handle this case properly?
>
> Regards,
> Alexander
> --
> Dr. Alexander Nyßen
> Dipl.-Inform.
> Principal Engineer
>
> Telefon: +49 (0) 231 / 98 60-202
> Telefax: +49 (0) 231 / 98 60-211
> Mobil: +49 (0) 151 /  17396743
>
>
http://www.itemis.de
> alexander.nyssen@xxxxxxxxx
>
> itemis AG
> Am Brambusch 15-24
> 44536 Lünen
>
> Rechtlicher Hinweis:
>
> Amtsgericht Dortmund, HRB 20621
>
> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus
>
> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino
>
>
>
> _______________________________________________
> eclipse.org-architecture-council mailing list
> eclipse.org-architecture-council@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
>
> IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.

_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.



Back to the top