Re: [cross-project-issues-dev] Is it time to update to Guava 18?
My specific interests are OCL and QVTd that depend on Xtext that uses
Guava, so I have no problem, but my users do.
'SimRel products' that would need to recode for Mars under your policy
are at least Papyrus and probably BIRT.
One of Eclipse's good features is that you can just create an
added-value product from A and B using the shared infrastructure and the
enforced release synchronisation.
Under your suggested partial wrapper policy, the developers of the
added-value product must check all components for 'shared' non-singleton
libraries and must choose which of to wrap in order to hide any
potential API conflict. I'm not convinced this is always possible, since
frameworks often provide call-backs whose API may inhibit wrappers. If
your policy was advocated, I would argue for a stronger policy that
prohibited any SimRel project from exposing any non-singleton library in
its API thereby guaranteeing that A and B are integrateable just as they
always used to be. IMHO SimRel requires its components to be generally
re-useable. Therefore both A and B must react, not the integrator.
You expose a problem with incremental install-time wiring. I'm not
familiar with this, but it seems to be a straightforward bug.
Installation of C should enforce a rewiring if consistency requires it.
My theory is based on run-time wiring. I suppose that when application C
that integrates A and B starts up, a version of Guava is chosen that
suits the uses directives of A, B and C. A and B run with this mutually
acceptable version. I assume that another integrating application D
might start up and make a different mutually acceptable decision so that
a different A and B run with D's version. Maybe my ignorance of Equinox
details is showing here. If A and B are singletons and so allow only one
run-time as well as only one installation version, then the enfoprcement
of a mutually compatible Guava must indeed be done by Equinox
Clarifying why integration may fail.
case 1: compile time.
A allows Guava [12..15)
B allows Guava [16..18)
An integration by C of both A and B should get a MANIFEST.MF error
diagnostic that no mutually compatible version of Guava can ever be found.
case 2: 'run' time.
A allows Guava [12..16)
B allows Guava [15..18)
Guava 17 is installed.
An integration by C of both A and B could get a MANIFEST.MF warning
diagnostic that no mutually compatible version of Guava is available.
A launch of C should get a run-time failure because Guava 17 is not
suitable, and a diagnostic recommending installation of Guava 15 to
solve the problem.
On 25/03/2015 10:54, Andreas Sewe wrote:
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
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?