Community
Participate
Working Groups
See bug 427862 for some background about the problems multiple versions of Guava can cause. Currently Sirius uses Guava 11.0.2: * we depend on it (through Require-Bundle); * some of our bundles re-export it (at least org.eclipse.sirius.ecore.extender); * some of our APIs may "leak" Guava types. I don't have an example in mind but we have never been particularly careful about that. It's not completely clear what's needed here, but given the discussions in bug 427862, we should be ready to work with more recent Guava versions (15 or 16). Given that we want to keep compatibility with Juno, Kepler and Luna, one option would be to make sure Sirius only uses parts of Guava which work from 11.0.2 through 16 (and are not deprecated in 16), and change our dependencies ranges to reflect that.
See https://git.eclipse.org/r/22504 for proposed changes. The result should still compile with Guava 11.0.2 (I did not change our target platform deinfitions) It also compiles using Guava 15 from http://build.eclipse.org/orbit/committers/orbit-I/20140224171915/I20140224171915/repository/. I also removed the only re-export of Guava I could find, in org.eclipse.sirius.ecore.extender.
See also https://git.eclipse.org/r/22507 to update our target platform definitions accordingly. Note that opening our dependencies range means we now get Guava 12 from the Orbit site we use.
We still need to: * check if/how much of our APIs "leak" Guava-specific types, and reduce that where possible; * understand how the OSGi "uses" directives work and add them if/when required in Sirius. See http://spring.io/blog/2008/10/20/understanding-the-osgi-uses-directive/ and http://njbartlett.name/2011/02/09/uses-constraints.html for this (I believe the second link is the best). For the first point, a quick check with the following command: find . -type f -name "*.java" | grep -v "internal" | xargs grep -l "^import com.google" | sort -u gives 208 Java source files which are not in packages explicitly named "internal" and which use Guava specific types. Note that this does not mean they leak Guava types; a
[previous comment submitted too early by mistake. here is the full version] We still need to: * check if/how much of our APIs "leak" Guava-specific types, and reduce that where possible; * understand how the OSGi "uses" directives work and add them if/when required in Sirius. See http://spring.io/blog/2008/10/20/understanding-the-osgi-uses-directive/ and http://njbartlett.name/2011/02/09/uses-constraints.html for this (I believe the second link is the best). For the first point, a quick check with the following command: find . -type f -name "*.java" | grep -v "internal" | xargs grep -l "^import com.google" | sort -u gives 208 Java source files which are not in packages explicitly named "internal" and which use Guava specific types. Note that this does not mean they leak Guava types; I expect that a lot of them use Guava only internally and not in public or protected fields or signatures. I don't know any automated way to check that (maybe with API tooling, but we don't use it).
Using the automatic computation of "uses" directives by PDE (the "Calculate Uses" button on the Runtime tab of the manifest editor), it seems 19 Sirius packages "leak" at least one type coming from Guava. I'll attach a coarse-grained report of which packages are concerned.
Created attachment 240465 [details] Coarse-grained report of Sirius packages that leak Guava types
If there had been only a handful of leaks, it might have been worth the effort to remove them and become completely "clean" in this regard. However given the number of cases, we can not reasonably do it, at least for M6. I'll close this particular ticket, because we have clearly reduced our dependency on a specific Guava version, with a much larger compatibility range. Regarding the leaks, I'll open a new ticket, but it's not clear yet what actions are needed. I'll keep an eye open on bug 427862 and see if general community rules or guidelines emerge from the discussion.
org.eclipse.sirius.editor still have a bundle-version="[11.0.0,12.0.0)". The maximum excluded version should be 16.0. See https://git.eclipse.org/r/#/c/23139/ which add a maximum Guava version in org.eclipse.sirius.ext.emf See also https://git.eclipse.org/r/#/c/23140/ which modify the luna target/targetplatform to look for Guava in Orbit only (consistent with Kepler and Juno targets behavior).
The wrong maximum version has been corrected in https://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=5cad127411e640ddae182d515d9b69ef689da348 The consistency in luna target will be treated in M7.
Verified on the latest source (commit 5cad127411e640ddae182d515d9b69ef689da348).
Available in Sirius 1.0.0M6 (see https://wiki.eclipse.org/Sirius/1.0.0M6).
