[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Guava 15/21 warning

Hi Gunnar

I seem to be a piggy-in-the-middle on this. My projects (OCL and QVTd) consume Guava solely via Xtext and so I can delegate my Guava selection to Xtext. Not my problem. However I tend to be an early integrator and so when I see my consumers such as Papyrus suffering, sometimes in my code, I try to help. Unfortunately since this is an area where I have intuition but no significant expertise, I can only relay the problem and promote hypotheses as to what the root issue is. StackOverflow may well be where some good experts can be found and once a solution has been identified, Bug 437107 should be the vehicle for ensuring that the solution is adopted across the full SimRel. IMHO a SimRel 'aggregation' report should somehow fail if a conflicting Guava could cause a SimRel-only Eclipse user to have a Guava problem. From Luna, Mars, Neon we know a really simple workaround; just one agreed Guava.

(Today while trying Java 9 and M6, my code failed to build; Iterators.emptyIterator() was fine in Guava 15, deprecated in Guava 19, removed in Guava 21. A bit of investigation identified Mylyn as the 'innovators' who had not announced their change. I started this thread to highlight the risk that the nightmare we had between Luna RC1 to RC3 could recur. For Luna RC4, everyone tolerated Guava 15.)


        Ed Willink

On 14/03/2017 14:37, Gunnar Wagenknecht wrote:

I think a single global bug as well as cross-project is a bad place for discussing OSGi questions. We encourage our users not to open bugs for questions and be diligent and go the extra mile to do some research and reach out via forums. I believe as committers we should behave similar and also use such channels for questions and discussions to allow others participate and to lower the disruption for people relying on cross-project for announcements/project coordination. My apology if I get your intention wrong and you are not using cross-project as a general help channel for issues you have.

FWIW, I think your best bet right now is StackOverflow. There is a huge OSGi community there that can help answering your questions around uses constraint. If you feel there is a gap around tooling you could ask there as well what other people are using and/or suggest improvements to PDE (if you think there is a lack). I agree that uses constraint are almost impossible to get right manually. However, the PDE "Organize Manifest" wizard has a checkbox which works for straightforward cases.


Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx, http://guw.io/

On 14 Mar 2017, at 14:59, Ed Willink <ed@xxxxxxxxxxxxx> wrote:

Hi Gunnar

There is no problem with Orbit, given the need to allow Guava to be a non-singleton.

If you have a technical solution that allows multiple Guava versions to co-exist, please add it to Bug 437107. My current understanding is that "uses" directives may be a solution but that no demonstration has been performed and so the requirements for tooling are at best guesses and of course not yet implemented. It is unlikleyt that any project currently complies with any potential "uses" solution.

IMHO Bug 437107 requires a solution, not a WONTFIX. Until we have a demonstrable solution with associated tooling, I feel we need to stick with the Luna 'solution'; all project's Guava dependency bounds include at least an agreed version and only that version is bundled, so only that version is used in practice.


        Ed Willink

cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Avast logo

This email has been checked for viruses by Avast antivirus software.