Hi, I am not sure if this actually is a problem, but it might be something to watch: If I interpret the latest unique version repo reports (http://download.eclipse.org/releases/staging/buildInfo/reporeports/reports/nonUniqueVersions.txt <http://download.eclipse.org/releases/staging/buildInfo/reporeports/reports/nonUniqueVersions.txt>) correctly, they seem to indicate that some projects are still pulling in Guava 12:
com.google.guava
12.0.0.v201212092141
15.0.0.v201403281430
It might of course also happen because some lower version bounds are taken too
literally within the aggregation, but as I haven’t investigated that in detail,
I thought it would make sense to point that out here.
Cheers
Alexander
> Am 25.03.2015 um 15:42 schrieb Ed Willink <e...@willink.me.uk>:
>
> Hi
>
> 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.
>
> Regards
>
> Ed Willink
>
>
> On 25/03/2015 10:54, Andreas Sewe wrote:
>> 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>
>>
>
> _______________________________________________
> 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
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer
Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
http://www.itemis.de
alexander.nys...@itemis.de
itemis AG
Am Brambusch 15-24
44536 Lünen
Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens
Trompeter, Sebastian Neus
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer
Fiorentino
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 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
