|Re: [cross-project-issues-dev] Guava 15/21 warning|
Great, you sound like an expert who has demonstrated a solution.
Can you contribute a wiki page on how you do it?
Can you identify what checks a SimRel report should do to detect projects that are doing it wrong?
On 14/03/2017 14:21, Andreas Sewe wrote:
Hi,If you have a technical solution that allows multiple Guava versions to co-exist, please add it to Bug 437107. My current understanding is that "uses" directives may be a solution but that no demonstration has been performed and so the requirements for tooling are at best guesses and of course not yet implemented. It is unlikleyt that any project currently complies with any potential "uses" solution.not true. Code Recommenders has exported interfaces  which have Guava classes in their public signature. However, Code Recommenders  properly declares these uses constraints and has not seen a major problem since we introduced this in 2013(!). Yes, if consumers of the org.eclipse.recommenders.models API also want to use Guava for other purpose, then they are restricted in their choice of Guava versions by what org.eclipse.recommenders.models uses but that's how OSGi works. This is IMHO a small price to pay for generally being able to have two versions of the same bundle in your runtime. No more "one classpath to rule them all", which *might* work in the closely coordinated simultaneous release (although based on  I doubt it), but certainly not once third-party plug-ins come into play. Best wishes, Andreas  <https://git.eclipse.org/c/recommenders/org.eclipse.recommenders.git/tree/plugins/org.eclipse.recommenders.models/src/org/eclipse/recommenders/models/IModelIndex.java?h=v2.4.6#n36>  <https://git.eclipse.org/c/recommenders/org.eclipse.recommenders.git/tree/plugins/org.eclipse.recommenders.models/META-INF/MANIFEST.MF?h=v2.4.6#n39>  <https://hudson.eclipse.org/simrel/job/simrel.neon.runaggregator.BUILD__CLEAN/lastSuccessfulBuild/artifact/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt>