Re: [cross-project-issues-dev] Is it time to update to Guava 18?
> On 25/03/2015 10:24, Andreas Sewe wrote:
>> Possibly, but being open to third-party plugins, we cannot prevent the
>> presence of multiple Guava versions in general.
>> Anyway, I think the burden is on the developers of integration bundles
>> C. You *can* shield yourself from this problem (A and B both exposing
>> Guava in their API) to wrap one of them into facade that does not expose
>> Guava in its API.
>> +-- A (exposes X) -- X
>> +-- B' -- B (exposes Y) -- Y
>> That way, A and B can be wired to different versions of Guava (X and Y,
>> respectively) but C can still make use of them both.
>> Granted, this is cumbersome, but (given the way OSGi and Equinox work)
>> the only solution that is will work in an open ecosystem where *anyone*
>> may supply another Guava bundle.
> Yes. That could work, but not for Mars because it imposes a new
> requirement on all SimRel products that integrate multiple Guava users.
> But it severely undermines Eclipse as a useful integration platform.
I don't quite understand. What do you mean by "SimRel products". IMHO,
the burden is solely with bundles C which depend on multiple bundles A
and B that expose Guava in their API. If the developers of C do their
homework, then the maintainer of a "SimRel product" (I assume you mean
something like ann EPP package) does not have to worry about multiple
Guava's being shipped as part of that product.
> IMHO, and I think 'uses' does this, then if A and B announce what they
> use, then the class loader for the integrator chooses a jointly
> compatible Guava.
I thought so, too, but (as Thomas Watson explained ) with Equinox
this is unfortunately not always the case. Here's the scenario:
- Bundle A requires either Guava version X or Y
- Bundle B requires Guava version Y
- C requires both A and B.
All bundles have correct uses constraints.
- A is installed first (causing version X to be installed)
- Equinox wires A to X
- B is installed second (causing version Y to be installed)
- Equinox wires B to Y
- C is installed
- Equinox cannot wire C to A and B *without* requiring A to Y
As Equinox (without "-clean") won't rewire existing bundles, C cannot be
resolved, even though a solution exists.
A similar situation arises if C = B, i.e., C both requires Guava itself
and a bundle A that exposes Guava in its API. But with three bundles
things are easier to explain, even though the two-bundle scenario is
probably more common.
> If this fails, most commonly this will be a compile
> time version failure because A and B have no overlap; an integrator's
> bug. Rarely it may occur at run-time if no Guava version from the
> overlap is available, a user's bug. Both are sensible, diagnosable and
> fixable leaving Eclipse as a good flexible integration platform.
Sorry, I don't understand what you are saying here. Can you please
reword and possibly expand your explanation?
The knowledge transfer company
Robert-Bosch-Str. 7, 64293 Darmstadt
Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940