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
On 14/03/2017 13:45, Gunnar Wagenknecht
wrote:
Both bugs are assigned to nobody and in the Cross-Project
component. I'm not sure who is responsible. However, it seems
impossible to address them as there is no clear path to decide
on. It looks like their main purpose is a sink for
discussions. I'd suggest closing them as WONTFIX. It doesn't
look like they'll ever be solved.
The problem never occurs for individual
projects. It only occurs when an integrating project
'inherits' conflicting Guava loads from two distinct
component projects with Guava in the APIs.
So Mylyn only is no problem, but something
that integrates Mylyn and Xtext can encounter obscure
failures when the wrong class is re-used on a code path
in which both are used.
FWIW, there are technical solutions to allow projects to
co-exist consuming different versions of Guava. Yes it is
complicated and gets even more complicated when projects are
re-exporting Guava as part of their APIs. But there are
solutions that work.
If you believer there are specific problems with regards
to the Guava libraries in Orbit please open a bug for Orbit
with more details (eg., exceptions). We'll look at
addressing them.
-Gunnar
_______________________________________________
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
|
