| Re: [eclipse.org-architecture-council] Discussing Hard Requirement for Guava 21 in Oxygen |
| 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 Here in another example: - 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
|