|Dear planning council,|
Dear Eclipse committers,
I strongly question this decision for the following technical reasons. The arguments referenced at  have been discussed controversially and have severe drawbacks:
- Upgrading to Guava 21 forces every project with Guava classes in their public API to make a new major release with every new Eclipse release. Otherwise we’d break every existing client out there (of Mylyn, of Code Recommenders, or every commercial or in-house project that builds on Xtext) for no good.
- Version ranges (in require-bundle or import-packages) will be required in any case: Even with the proposed solution, we will have the same problem as today as soon as any other 3rd party requires/uses a later version of Guava. Thus, forcing a subset of Eclipse plugins to use Guava 21 w/o version ranges will break plug-ins.
- The argument made in  that uses directives are "too hard to use" is weak and, in my opinion, does not justify the drawbacks of 1 & 2.
I understand that all projects that rely on Xtext (as Ed’s projects) suffer from the fact that different versions of Guava can be around and thus can cause wiring issues. But the proposed solution does that fix for Ed’s use case but breaks an unknown number of clients out there we don’t know yet. IMO (and others supported that previously), this is a effort that needs (and can!) to be solved by the Xtext community - but not on the cost of every other project out there.
I, however, agree with the statement (made in  as well) "Please move to Guava 21. If you can do accurate 'uses' directives, please do that”. Projects that can properly make use of uses directives should not be forced to update their code and all clients to Guava 21, Guava 22, Guava 23…
I’ll take this to the architecture council on next Thursday for further discussion. Since several planning council members are also on this council, I think we’ll have every interest group represented there. If not, I’m sure the AC welcomes every other committer to join this call.
On 5. May 2017, at 10:04, Aleksandar Kurtakov <akurtako@xxxxxxxxxx> wrote:
On the last Planning council meeting we discussed Guava and having
multiple versions of it in Oxygen. In order to prevent issues like
there were with multiple Guava versions in Luna and/or issues like
with Neon.3 we are strongly recommending that:
Every project that depends on Guava moves to version 21 for Oxygen.
Guava 21 is available in Oxygen's M6 repo so please file your PB CQs
and move up ASAP.
Detailed report of all the API changes since version 15 (the version
in Neon) can be found at
Don't hesitate to ask if there is anything unclear.
Red Hat Eclipse Team
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit