Avoid implicitly compiling sources from the classpath #149
Comments
Includes a workaround for google/compile-testing#149 RELNOTES=n/a ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=198895795
Includes a workaround for google/compile-testing#149 RELNOTES=n/a ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=198895795
The GWT sources (specifically, GwtSerializationDependencies) use @nullable directly, so we shouldn't rely on relying on it indirectly through guava-jre. However, what actually prompted this is a strange behavior in Compile-Testing, which Truth uses. This CL should help, though it might not be a fully solution. google/compile-testing#149 RELNOTES=n/a ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=198882337
The GWT sources (specifically, GwtSerializationDependencies) use @nullable directly, so we shouldn't rely on relying on it indirectly through guava-jre. However, what actually prompted this is a strange behavior in Compile-Testing, which Truth uses. This CL should help, though it might not be a fully solution. google/compile-testing#149 RELNOTES=n/a ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=198882337
|
Setting |
|
I don't think this is the problem you're hitting, but just in case, and to raise awareness of this weirdness, an empty source path apparently doesn't play well with module ( |
|
Weird! I went looking and found gradle/gradle#2356 (and slightly related gradle/gradle#2330), albeit without a clear indication of whether this is an intentional javac behavior or a bug. I agree that that's not likely to be the problem I'm hitting here, but it sounds likely to bite in the future, so thanks. |
|
Error from a module not on the sourcepath is...
...which I guess sounds intentional, if sad, given that I've read your https://blog.ltgt.net/most-build-tools-misuse-javac/ Searching for that leads to gradle/gradle#2302 (edit: also gradle/gradle#3035) |
You can see some internal discussion on CL 198652081, but in short:
guava-gwt.guava-gwtjar contains.javafiles..javafiles.guava-androidbutguava-gwtusesguava-jre, Maven putsguava-androidon the classpath whenguava-gwtneedsguava-jreand its dependencies. So now the compilation fails.We're going to work around this by:
-sourcepath ''to Compile-Testing.guava-gwtto some dependencies that it uses directly but currently gets transitively throughguava-jre.But maybe Compile-Testing should be setting
-sourcepath ''internally automatically? (Or maybe there's something else similar it should be doing; I've heard that all this is surprisingly complex.)On the other hand, probably few people will be affected by this: They won't have
.javafiles on their classpath, and even if they do, the files will compile fine because the dependencies will be there. Still, I wonder if they will see unexpected warnings or other output in some cases. (Maybe I've seen some reports of weird Compile-Testing behavior before in AutoValue or something? I'll see if I can dig anything up.) And presumably it's at least a little wasteful to compile files that we don't need.The text was updated successfully, but these errors were encountered: