plexus-compiler-eclipse: some warnings from APT processors are lost #68
Comments
Instead of invoking BatchCompiler with an option to write diagnostics to a temporary XML file and then parsing that call ECJ via the standard JSR-199 interfaces and use a DiagnosticListener. Besides not needing a temporary file this also ensures that all diagnostics are reported correctly. ECJ's BatchCompiler reports diagnostics from APT processors differently than other diagnostics (they're "extra_problems" in the XML), and the XML parser just ignores these extra_problems. Even if it did parse them, ECJ up to at least 3.20.0 neglects to give the source file for such extra_problems in the XML (that's a bug in ECJ), and thus the output would be not exactly helpful. Using JSR-199 to call ECJ, it reports all diagnostics including these "extra_problems" (with source file!) to the DiagnosticListener, and thus no messages are lost. A minor quirk is that when no source level is specified, BatchCompiler compiles with source level 1.3, while the ECJ JSR-199 implementation uses the latest source level it supports (Java 12 for ECJ 3.20.0). To maintain backwards compatibility, set source level 1.3 explicitly in that case. In normal maven usage, <source> is typically set anyway, either explicitly in the user projects' POMs or via property maven.compiler.source. If no JSR-199 interface for ECJ can be found keep using the legacy mechanism using BatchCompiler.
|
See PR #69. |
Instead of invoking BatchCompiler with an option to write diagnostics to a temporary XML file and then parsing that call ECJ via the standard JSR-199 interfaces and use a DiagnosticListener. Besides not needing a temporary file this also ensures that all diagnostics are reported correctly. ECJ's BatchCompiler reports diagnostics from APT processors differently than other diagnostics (they're "extra_problems" in the XML), and the XML parser just ignores these extra_problems. Even if it did parse them, ECJ up to at least 3.20.0 neglects to give the source file for such extra_problems in the XML (that's a bug in ECJ), and thus the output would be not exactly helpful. Using JSR-199 to call ECJ, it reports all diagnostics including these "extra_problems" (with source file!) to the DiagnosticListener, and thus no messages are lost. A minor quirk is that when no source level is specified, BatchCompiler compiles with source level 1.3, while the ECJ JSR-199 implementation uses the latest source level it supports (Java 12 for ECJ 3.20.0). To maintain backwards compatibility, set source level 1.3 explicitly in that case. In normal maven usage, <source> is typically set anyway, either explicitly in the user projects' POMs or via property maven.compiler.source. If no JSR-199 interface for ECJ can be found keep using the legacy mechanism using BatchCompiler.
|
Thanks for merging. What's going on with the Travis builds? jdk8/9 fails consistently, jdk11 succeeds. I suppose this issue could be closed since the PR is merged. When could we expect a release with this? |
|
switching to openjdk fix the problem |
|
release done :) |
|
Thanks. Just built a fairly large Spring Boot project with this; works well. In fact, it works too well: it emits the missing warnings, but also shows a few other warnings that previously were hidden, in particular Both are also visible with plexus-compiler-eclipse 2.8.5 if maven is run with -X. Don't know where exactly the first one comes from... The second one is actually another ECJ bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=560204 . Hibernate emits this as an INFO, but ECJ reports any non-error message as a warning. |
|
While https://bugs.eclipse.org/bugs/show_bug.cgi?id=560204 is fixed in the upcoming ECJ 3.22.0, the switch to JSR-199 also exposes another ECJ bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=563654 : sometimes ECJ reports suppressed warnings. A fix is pending in ECJ at https://git.eclipse.org/r/#/c/163738/ . And there's follow-up issue #73 (configured encoding not respected), for which there is PR #74 pending here. |
See Eclipse bug 559645 for context and a sample Eclipse maven project showing the issue.
Basically, ECJ reports these diagnostics from APT processors as "extra_problem" elements in the log XML. plexus-compiler-eclipse completely ignores these when parsing the XML to get the diagnostics. Even if it did parse them, ECJ at least up to 3.20.0 has a bug and doesn't report the source file for these extra_problems in the XML, so the output would not be really helpful.
The text was updated successfully, but these errors were encountered: