[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cross-project-issues-dev] Is it time to update to Guava 18?
|
Hi Ed,
> 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
>> /
>> C
>> \
>> +-- 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 [1]) 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?
Best wishes,
Andreas
[1] <https://bugs.eclipse.org/bugs/show_bug.cgi?id=438453#c13>
--
Codetrails GmbH
The knowledge transfer company
Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/
Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940