Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
1 task done
tbroyer opened this issue Apr 1, 2024 · 2 comments
Closed
1 task done

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

tbroyer opened this issue Apr 1, 2024 · 2 comments
Assignees
Labels
Milestone

Comments

@tbroyer
Copy link

tbroyer commented Apr 1, 2024

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

@tbroyer tbroyer added the type=defect Bug, not working as expected label Apr 1, 2024
@cpovirk cpovirk self-assigned this Apr 2, 2024
copybara-service bot pushed a commit that referenced this issue Apr 11, 2024
Fixes #7134

(tested using the sscce.zip from that issue, adding `mavenLocal()` to the top of its `repositories` and updating `guava-gwt` to `HEAD-jre-SNAPSHOT`)

RELNOTES=Fixed [Gradle GWT compilation breakage](#7134).
PiperOrigin-RevId: 623819484
@cpovirk
Copy link
Member

cpovirk commented Apr 11, 2024

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.

copybara-service bot pushed a commit that referenced this issue Apr 11, 2024
Fixes #7134

(tested using the sscce.zip from that issue, adding `mavenLocal()` to the top of its `repositories` and updating `guava-gwt` to `HEAD-jre-SNAPSHOT`)

RELNOTES=Fixed [Gradle GWT compilation breakage](#7134).
PiperOrigin-RevId: 623819484
copybara-service bot pushed a commit that referenced this issue Apr 11, 2024
Fixes #7134

(tested using the sscce.zip from that issue, adding `mavenLocal()` to the top of its `repositories` and updating `guava-gwt` to `HEAD-jre-SNAPSHOT`)

RELNOTES=Fixed [Gradle GWT compilation breakage](#7134).
PiperOrigin-RevId: 623819484
@tbroyer
Copy link
Author

tbroyer commented Apr 11, 2024

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.

@cpovirk cpovirk added this to the 33.2.0 milestone May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
2 participants