guava: guava-27.0-jre.jar contains failureaccess class files

@cgdecker The approach you have taken to splitting out a submodule is indeed very standard, and well suited to corporate codebases and larger projects. But for a foundational library like Guava it is far from ideal. Put simply, it is not the case that all users ignore the number of jar file dependencies - for some users, details of, and number of, those dependencies really matters,

There are going to be plenty of projects that have a dependency on Guava and nothing else. Those projects will now be seeing a tripling of the number of dependencies. This affects me (more or less) with Joda-Beans and Joda-Convert.

In addition, many projects (like OpenGamma Strata) have to list all their dependencies in user documentation, and the version numbers thereof. The change requires both new dependencies to be added to the docs, and some kind of additional note added to try and explain the horrible v9999 hack.

In essence this gives the appearance of Google making a change for its convenience (Android) rather than providing stability and security for non-Google users, which is what some of us have worried about all along with Guava. Particularly as now the floodgates of dependencies are open I fear we willl see Guava split into many more jar files.

@cgdecker Removing these classes from the main jar is not the right solution though. We care about the number of jar file dependencies, so splitting Guava into multiple pieces is very painful. And pushing a v9999 hack on the world really is a gross failure on the part of Guava maintainers.

Given that you have separate releases for -jre and -android, surely the -jre release should just be a single jar file, with the -android release split into pieces. This would avoid all the problems you are seeing.

same for com.google.guava:guava:27.0-android

Program type already present: com.google.common.util.concurrent.internal.InternalFutures

@stari4ek try to use this implementation:

`  implementation(group: 'com.google.guava', name: 'guava', version: '27.0-jre') {
    exclude group: 'com.google.guava' , module: 'failureaccess'
}`

@cgdecker I have never used OSGI, so this may be a dumb question: When one builds the failureaccess jar, is its META-INF/MANIFEST.MF expected to contain an Export-Package line and a bunch of Bundle--prefixed lines?

I ask because when I pull your changes and then build failureaccess with mvn clean install, its MANIFEST.MF does not contain those lines. It’s strange… I see another MANIFEST.MF that does contain those lines outside of the jar – in my target/classes/META-INF directory – but the one inside the jar is more basic. Do you see the same thing? Am I running the wrong command to build failureaccess?

Edit: Ohh, I think you need to add <packaging>bundle</packaging> in the failureaccess pom. That fixes the wrong-looking manifest in the jar for me locally.

I think this is also a problem with JPMS modules, where the same package is in guava.jar and failureaccess. Are we (non android projects) supposed to exclude failureaccess ? ( I’ve read https://groups.google.com/forum/#!topic/guava-announce/2nR5GdDdBYo but it isn’t clear for me)

the unnamed module reads package com.google.common.util.concurrent.internal from both com.google.common and failureaccess