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
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
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
![Avast logo]()
|
This email has been checked for viruses by Avast antivirus software.
www.avast.com
|
