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.)
Regards
Ed Willink
On 14/03/2017 14:37, Gunnar Wagenknecht wrote:
Ed,
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
--
Gunnar Wagenknecht
[email protected] <mailto:[email protected]>, http://guw.io/
On 14 Mar 2017, at 14:59, Ed Willink <[email protected]
<mailto:[email protected]>> 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.
Regards
Ed Willink
_______________________________________________
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
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
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
