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 _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev