-
Notifications
You must be signed in to change notification settings - Fork 27
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
Publish a GWT module #184
Comments
If we're only talking about annotations, then there's no need for anything special IIRC (will double-check just in case) |
The man himself! Thank you. I've been figuring we'd want to loop you in for JSpecify in general (if we hadn't at least once already?), but obviously I had you in mind for this particular question. My experiments with Guava suggest that there's something specifically problematic about type annotations only if they appear in locations where only a type annotation would be valid (like |
I did a few quick tests, and the issue you have with For Guava, I would suggest doing something similar to what Dagger does for For JSpecify, to play safe (particularly given that it has zero dependency), you'd only need to have an The main (maybe only) difference between Truth and Guava/Dagger approaches is with transitive dependencies. Truth's way uses the same POM for both flavors, so it cannot declare additional GWT-specific dependencies (such as source JARs); whereas Guava and Dagger both provide artifacts at separate coordinates, where the POM can then declare additional dependencies. Using Truth with GWT means adding two dependencies (the binary JAR and the GWT-specific JAR), whereas with Guava or Dagger you add the dependency to the GWT-specific artifact, which will pull the "normal" artifact transitively (for JavaC, and annotations, for which GWT needs the bytecode). |
I don't think we have an Official Process yet in place for moving issues between milestones, so I'm just going to mark this as post-1.0 unilaterally and then attempt to justify myself :) As part of Guava 31.0.1, I changed our build process to strip It will still be nice to publish a JSpecify GWT module eventually (and maybe we'll even do it before 1.0, since it doesn't sound too hard), but anything we can do after 1.0 is worth considering doing after 1.0. |
(Another possible complication here is |
Internal testing suggests that we're probably going to need to add But it's also possible that, when we generate the jar of GWT sources, we could just remove |
I was going to add "Or we could omit |
GWT matters to relatively few Java developers, but I'm getting the impression that we're going to need to publish a GWT module if we want to be able to use it from Guava and our other projects that support GWT.
(Maybe there's an alternative in which the build systems for those projects rewrite the sources to omit our annotations, but that seems ugly, and it hides the nullness information from any tools that might consume it when compiling the client-side GWT code. Granted, I wouldn't expect nullness information to be used by the normal GWT compiler, but it could plausibly happen with the j2cl compiler.)
I have gotten Guava to depend on the Checker Framework annotations without having an official GWT module for them, but it's a bit ugly, and I suspect that users of Guava's GWT module will fail to compile because they won't see the custom GWT module we set up for the Checker Framework inside our build.
And I just now discovered that the approach I was employing is wrong because it results in bundling the Checker Framework annotations into the guava-gwt jar :)[edit: now fixed] (Oddly, we were able to use the Checker Framework annotations just fine until that commit. The difference seems to be that we're now introducing an annotation in a location at which it must be a type-use annotation. Previously, we'd used Checker Framework annotations only in locations where they could also be declaration annotations.)So my guess is that my life will be simpler if I just create a JSpecify GWT module, rather than try to hack around the absence of one and maybe end up with a crisis :)
There are at least 2 questions here:
Possibly useful links:
gwt-lib
dependency and re-compiling changes tbroyer/gwt-maven-plugin#31 (comment)The text was updated successfully, but these errors were encountered: