Marcel,
I think there is some confusion with the actual implications. It's my understanding that the proposed solution only affects the Oxygen release train *and* (more specific) is only relevant to the Oxygen release train repository and the Eclipse packages. Any commercial vendor is still able to continue shipping the specific version of Guava it prefers, as long as the projects using Guava guarantee compatibility to that version. When a commercial vendor decides that it wants to adopt Oxygen then it will need to test and may need to touch its code. Isn't that expected behavior?
Please keep in mind that Eclipse API has a commitment to backwards compatibility. However, I don't think that commitment covers 3rd party API. If clients are using 3rd party API, then they need to retest and ensure that their code is working with a specific version.
Can you please be more specific about the expected breakage?
Here in an example: - Code Recommenders increase the version range to Guava [15, 22). - Oxygen ships *only* Guava 21 - Code Recommenders Extension ABC defines a narrower dependency version range - user installs Code Recommenders Extension ABC - p2 will install a lower Guava version a) Extension will work as expected, Code Recommenders *and* Extension will use lower Guava version b) Extension will not work because of ...? c) Code Recommenders and others break because...? d) Eclipse installation will be hosed
- Oxygen ships *only* Guava 21 - User installs Plug-in "ABC", which defines a narrower dependency version range => p2 will install a lower Guava version a) Plug-in will work as expected, Code Recommenders and others continue to work using the newer Guava version b) Plug-in will work as expected, Code Recommenders and others continue to work using the older Guava version c) Plug-in will work as expected, Code Recommenders and others break because...? d) Plug-in will not work, everything else continues to work e) Eclipse installation will be hosed
I'm also not sure I understand the major version requirement update. Are you re-exporting the *full* Guava bundle or are you re-exporting a specific Guava package? I was under the impression that this major version increase should only be done when you are actually re-exporting things. That's why re-exporting is not recommended
FWIW, Text is working hard on allowing their lib bundle to work with Guava 14-21.
FYI, here is an older discussion and a case where re-export was added back to retain binary backwards compatibility:
It sounds to me, as we should also make general recommendation for any post-Oxygen release: Get rid of Guava API pollution in Eclipse API. :) Guava seems to be a continuous source of frustration and a huge sink for developer time, which is causing terrible maintenance costs btw.
-Gunnar
Dear AC, I’d like to put this topic on Thursday’s agenda. It has severe and unnecessary consequences for the community. I posted my arguments here on the list a minute ago. If someone can disprove my technical arguments, please do so on the mailing list. This helps to document the issue and gives everyone a chance to understand the arguments made w/o time pressure. Thanks, Marcel _______________________________________________ eclipse.org-architecture-council mailing list eclipse.org-architecture-council@xxxxxxxxxxxhttps://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.
|