google / j2cl

Java to Closure JavaScript transpiler
Apache License 2.0
1.23k stars 144 forks source link

junit_processor fails to build with current junit version #153

Closed niloc132 closed 2 years ago

niloc132 commented 2 years ago

Describe the bug Introduced in roughly 1a51e3899b07062ea90a67b6ec150a4aad96a93f with the other Parameterized support, it is assumed by this patch that at least JUnit 4.13 is being used, since AfterParam, BeforeParam were introduced in that version. While bazel build //junit/emul/java:junit_emul does not fail (naturally, since it provides the emulation), bazel build //junit/generator/java/com/google/j2cl/junit/apt:junit_processor does, which attempts to use these annotations from the annotation processor.

To Reproduce Run

bazel build //junit/generator/java/com/google/j2cl/junit/apt:junit_processor

Observed results:

ERROR: /home/colin/workspace/j2cl/junit/generator/java/com/google/j2cl/junit/apt/BUILD:20:13: Building junit/generator/java/com/google/j2cl/junit/apt/libjunit_processor-class.jar (21 source files) and running annotation processors (AutoServiceProcessor, AutoAnnotationProcessor, AutoOneOfProcessor, AutoValueProcessor) failed: (Exit 1): java failed: error executing command external/remotejdk11_linux/bin/java -XX:-CompactStrings '--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED' ... (remaining 17 arguments skipped)
junit/generator/java/com/google/j2cl/junit/apt/JUnit4TestDataExtractor.java:49: error: cannot find symbol
import org.junit.runners.Parameterized.AfterParam;
                                      ^
  symbol:   class AfterParam
  location: class Parameterized
junit/generator/java/com/google/j2cl/junit/apt/JUnit4TestDataExtractor.java:50: error: cannot find symbol
import org.junit.runners.Parameterized.BeforeParam;
                                      ^
  symbol:   class BeforeParam
  location: class Parameterized
junit/generator/java/com/google/j2cl/junit/apt/JUnit4Validator.java:41: error: cannot find symbol
import org.junit.runners.Parameterized.AfterParam;
                                      ^
  symbol:   class AfterParam
  location: class Parameterized
junit/generator/java/com/google/j2cl/junit/apt/JUnit4Validator.java:42: error: cannot find symbol
import org.junit.runners.Parameterized.BeforeParam;
                                      ^
  symbol:   class BeforeParam
  location: class Parameterized
Target //junit/generator/java/com/google/j2cl/junit/apt:junit_processor failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 2.139s, Critical Path: 1.20s
INFO: 4 processes: 2 internal, 1 local, 1 worker.
FAILED: Build did NOT complete successfully

Bazel version

$ bazel version
Bazelisk version: v1.7.4
Build label: 5.1.0
Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Thu Mar 24 14:02:30 2022 (1648130550)
Build timestamp: 1648130550
Build timestamp as int: 1648130550

Expected behavior The processor should build correctly.

Other notes on testing Additional testing to confirm behavior is as expected is difficult, with the j2cl_test not functioning. Relying on just building with bazel build //junit/... doesn't work, and even being as specific as bazel build //junit/generator/java/com/google/j2cl/junit/async:* will fail, since the j2cl_library rule implicitly creates a libasync-j2wasm target, and that fails too (there is no //third_party:junit-j2wasm target available, shouldn't it be generated by virtue of the same rule generation that emitted async:async-j2wasm?).

I am hesitant to create a separate issue for these other problems, but instead to only focus on problems that I have a clear, obviously-correct patch for, since j2cl_test is pretty far down your backlog, and not something a non-Google is probably able to contribute (especially with so much non-building code in open source). With that said, let me know if it makes sense to itemize "this is probably not deliberately broken" if you think it would be constructive, otherwise I'll stick to workarounds that keep j2cl-maven-plugin stable and able to update to latest j2cl versions.

gkdn commented 2 years ago

Thanks.

I have prepared a patch that fixes more targets and enables testing of the relevant parts so we won't regress in open-source. Will submit that soon.