Dear planning council,
Dear Eclipse committers,

I strongly question this decision for the following technical reasons. The 
arguments referenced at [1] 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 [2] 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 [2] 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.


Marcel



[1] https://wiki.eclipse.org/Planning_Council/May_03_2017
[2] https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14350.html


> On 5. May 2017, at 10:04, Aleksandar Kurtakov <[email protected]> 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
> https://github.com/google/guava/wiki/ReleaseHistory .
> 
> Don't hesitate to ask if there is anything unclear.
> 
> -- 
> Alexander Kurtakov
> Red Hat Eclipse Team
> _______________________________________________
> cross-project-issues-dev mailing list
> [email protected]
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Reply via email to