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

Thanks Martin, Tom,

would you recommend to use uses-directives only for those third-party Orbit dependencies I mentioned, or in general for all third-party bundles (like org.eclipse.swt in our case)?

Regards,
Alexander

Am 18.04.2016 um 14:27 schrieb Thomas Watson <tjwatson@xxxxxxxxxx>:

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.


_______________________________________________
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.

--
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



Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


Back to the top