Re: [viatra-dev] Guava and Oxygen compatibility

[Zoltán Ujhelyi <zoltan.ujhelyi@xxxxxxxxxxxxxxxx>]

Hi all,

I have set up an updated the dependency settings in VIATRA that seems to work in case of Guava 15 and 21 are both installed (and I also understand why does it work) that was merged into master. The main task was to add ‘uses’ declarations to all package exports that have Guava available on the API and replace all RequireBundle declarations for Guava to Package-Import [1].

I have already tested that the development environment works as expected, all of our plug-ins were bound consistently to Guava 15 (Xtext in Oxygen will not bind with Guava 21 [2]). 

There are two cases that require further testing:

 1. We have to test what happens when we install a query and/or transformation project that was created with earlier versions of VIATRA. It is possible that most query/transformation projects will need no updates, but it has to be checked manually.
 2. It is also important to test whether we can work with code that is explicitly bound to another version of Guava, e.g. Papyrus. Again, I hope everything will work; but needs to be checked.

This change is merged into master; because almost all manifest files had to be updated, it is possible that I have messed up something. Please report any kinds of dependency issues you find, and we will have a look at it.

Best regards,
Zoltán

  [1] https://git.eclipse.org/r/#/c/96515/
  [2] https://dev.eclipse.org/mhonarc/lists/xtext-dev/msg01279.html
-- Zoltán Ujhelyi

Eclipse Technologies Expert
IncQueryLabs Ltd.

> On 2017. May 2., at 19:56, Zoltán Ujhelyi <zoltan.ujhelyi@xxxxxxxxxxxxxxxx> wrote:
> 
> Hi all,
> 
> this will be a long email; the short version is that the dual installation of Guava 15.0 and 21.0 causes critical issues with VIATRA and I am sharing the technical level plan to address it and what concerns do we foresee. The goal of this mail is mostly to give a heads-up of what is to be expected; but if anyone has some specific concerns here, feel free to share it.
> 
> ----
> 
> I have recently tried out installing the latest VIATRA 1.6 integration build to Oxygen M6 (Modeling distribution), and sadly found out that our development environment almost doesn’t work at all: in the Query result view, I could load models and patterns, but could not display the matches; the Rete visualizer, the Local search debugger and the Viewers Sandbox failed with various strange exceptions.
> 
> The root cause of all the exceptions was that half of our plug-ins were bound to Guava 15.0, while the other half to 21.0. Even worse, opposite what we have believed before, it is not enough to verify Guava does not appear on our APIs; I have seen a case were classes from Guava did not load 
> 
> This means, the strategy we decided two meetings ago to wait until the problem manifests itself, is not working; at the bare minimum we should enforce that all VIATRA plug-ins bind to the same Guava version.
> 
> Xtext was suspiciously bound to Guava version 15.0, so I checked what they were doing to achieve this: they were using a version range of [15.0.0,19.0.0) for their Guava dependencies, but did not do any other steps to ensure compatibility, which means to me, they are lucky that 21.0 is outside their supported range, making the current issue non-existent to them; but they are still vulnerable to the greater issue.
> 
> Papyrus went their way to enforce a Guava 21.0 dependency; this is interesting, as they are having some direct and indirect Xtext dependencies, so their dependencies include both versions of Guava.
> 
> We had a discussion with Ábel, and came forth with the following strategy:
> 
> 0. Removing all references on Guava is impractical/borderline impossible, as we are using it quite extensively in the codebase. Furthermore, Xtend generates Java code that also relies on Guava. If required, we could aim to remove some especially problematic cases, but in general Guava usage stays.
> 1. At first we try to add uses constraints to the exported package declarations in all the VIATRA plug-ins. If we are lucky, this might ensure all runtime plug-ins use the same Guava versions.
> 2. If this does not work, additionally we replace all Require-bundle declarations for guava to package imports. The best practice seems to combine uses constraints with Import-packages.
> 3. If this still does not work, we should limit our Guava usage to a single version. This has to be 15.0, as 21.0 requires Java 8.
> 4. Regardless of what way we go, we should ensure that all plug-ins refer to Guava using a consistent version or version range.
> 
> Open questions that will need further research and/or testing:
> a. If we should limit our Guava usage to a single version, we should explicitly test what happens when we try to execute queries/transformations over Papyrus that explicitly uses a different Guava version and test whether everything works as expected.
> b. It is unclear as of now whether or not query and transformation needs to be updated; and if yes, how expensive is to automate this update process for clients.
> 
> Best regards,
> Zoli
> -- Zoltán Ujhelyi
> 
> Eclipse Technologies Expert
> IncQueryLabs Ltd.
> 
> _______________________________________________
> viatra-dev mailing list
> viatra-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/viatra-dev