Re: [eclipse.org-architecture-council] Re-exporting dependency tofragmen

["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.