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

No, when we re-exported in the past on Platform we usually came to regret it later. One big problem is that it leaves the consumer at the mercy of the particular version range that is re-exported, which may or may not be exactly appropriate range for the transitive consumer. I think it is better overall to require clients to make their dependencies explicit, with the version range that they are built and tested against. The only valid case for re-export that I can think of, is when you refactor a bundle into multiple pieces and you leave behind the original bundle as a facade for compatibility reasons, with re-exports for the new smaller pieces. Of course you would never have to do that if everyone used package imports :)

John


On Tue, May 3, 2016 at 7:00 AM, Martin Lippert <mlippert@xxxxxxxxx> wrote:
Hey John,

would that mean when those original Eclipse platform bundles are used by the API of a bundle, you would use require-bundle AND also re-export that dependency?
I know that many of the original Eclipse platform bundles are designed to use require-bundle, but the re-export sounds rather dangerous to me…

Cheers,
-Martin




> I would recommend using import-package only in cases where the corresponding export-package defines a version number. In the case of SWT (and many original Eclipse platform bundles), they are designed to be consumed as entire bundles and don't list version numbers on their package exports. For such bundles I think you are better off sticking with Require-Bundle.
>
> John
>
> On Tue, Apr 26, 2016 at 2:28 PM, Alexander Nyßen <nyssen@xxxxxxxxx> wrote:
> 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
>
>
>
>
> _______________________________________________
> 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.


Back to the top