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 install-time wiring.
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:I don't quite understand. What do you mean by "SimRel products". IMHO,
Possibly, but being open to third-party plugins, we cannot prevent theYes. That could work, but not for Mars because it imposes a new
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.
requirement on all SimRel products that integrate multiple Guava users.
But it severely undermines Eclipse as a useful integration platform.
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 theyI thought so, too, but (as Thomas Watson explained ) with Equinox
use, then the class loader for the integrator chooses a jointly
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 compileSorry, I don't understand what you are saying here. Can you please
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.
reword and possibly expand your explanation?
cross-project-issues-dev mailing listcross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit