guava-gwt should publish Gradle module metadata or somehow fix POM

[tbroyer]

Description

Using guava-gwt from Gradle, when resolving a "runtime" configuration, the j2objc-annotations dependency is missing. This is because it's declared in the jreApiElements variant but not in the jreRuntimeElements one.

When using Maven, or explicitly disabling Gradle module metadata, the dependency will be there as it's declared with the default <scope>compile</scope> in Maven (Maven lacking an equivalent to Gradle's compileOnlyApi).

As a workaround, the dependency can be explicitly added to the project.

sscce.zip

Example

See attached project; build it with

./gradlew assemble

You can add --info to see the exact command-line for the GWT compiler.

Expected Behavior

Compilation should succeed.

Actual Behavior

Compilation fails, GWT complaining about the j2objc annotations.

Edit build.gradle.kts to uncomment the j2objc-annotations dependency and rebuild, now it should compile without error.

You can also run ./gradlew dependencies and compare the compileClasspath and runtimeClasspath dependency trees (note that the latter will also contain gwt-dev and all its dependencies):

./gradlew dependencies --configuration compileClasspath
./gradlew dependencies --configuration runtimeClasspath

Packages

No response

Platforms

GWT

Checklist

• I agree to follow the code of conduct.

[cpovirk]

Sorry for not getting to this sooner. Thanks for the easy repro. I have a fix on the way in #7153.

It does seem interesting that GWT would use the "runtime" configuration for its compilation. I guess GWT's runtime and compile time aren't as cleanly separable, since the output of compilation contains exactly what will be used at runtime. I could maybe see having GWT us "compile-time" instead (as an acknowledgment that some people like to omit source-retention annotations at runtime), but I could also believe that that causes problems of its own. And maybe there's a way to use the union of those, but maybe that causes problems, too :) Anyway, I'm happy to just fix it on our end.

[tbroyer]

The thing is that GWT loads everything from its own classpath when you run the compiler or codeserver, so for the GWT tooling itself you'd rather use the runtime dependencies (I'm not sure it makes much difference, I haven't checked though); and this also applies to other dependencies that "enhance" the compilation (through GWT generator and linker mechanisms), particularly their transitive dependencies that might not be GWT-aware.
Indeed ideally we'd want the union of compile-time and runtime dependencies but I'm not sure whether this is even possible with Gradle. This artifact being specific for use with GWT though, making sure both sets of dependencies are equivalent sounds like the safest approach: whichever consuming projects will use, they'll have all they need.