[
https://issues.apache.org/jira/browse/MCOMPILER-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17030171#comment-17030171
]
Benjamin Marwell commented on MCOMPILER-408:
--------------------------------------------
Robert, I totally agree that compilation which leads to packaging should go
into the compile phase.
I just wouldn't want to have non-optimized code which was compiled with such a
plugin in my final jar.
I see no reason why a second compilation step would be harmful when done with a
compiler plugin in another phase of the build.
The only other option I see would be to execute mvn a second time or
beforehand.
Or maybe I could make it a new Maven plugin which mimics the compiler plugin,
but leaves out setting the output. Is that reasonable?
Perhaps Google's choice to implement errorprone with a compiler plugin was a
bad idea, perhaps a bytecode scanner should be used for this job? As you have
more experience with maven, I would like to hear your opinion on this.
Btw, sorry for phrases like "unsatisfied with the outcome". I meant something
more technical like "I think this should be working, because of...".
> CompileMojo resets project artifacts when used in verify phase
> --------------------------------------------------------------
>
> Key: MCOMPILER-408
> URL: https://issues.apache.org/jira/browse/MCOMPILER-408
> Project: Maven Compiler Plugin
> Issue Type: Bug
> Affects Versions: 3.8.0, 3.8.1
> Environment: - Maven 3.6.2
> - Maven compiler plugin <any>
> - errorprone <any>
> Reporter: Benjamin Marwell
> Priority: Major
>
> h2. Problem Description / Setup
> I tried to execute the google error-prone plugin in the compile phase, but
> was unsatisfied with the outcome. However, it seemed to be a perfect fit for
> the {{verify}} phase. Other plugins will also use the verify phase, e.g.
> checkstyle. I will also compile it to a different folder (which is
> {{target/classes-errorprone}}).
> However, when using the CompileMojo, it will always call
> [projectArtifact.setFile(dir);|[https://github.com/apache/maven-compiler-plugin/blob/master/src/main/java/org/apache/maven/plugin/compiler/CompilerMojo.java#L189]].
> There is no possibility to override this.
> I do think this is not always the wanted behaviour.
> Now, when executing
> {code:java}
> mvn clean verify -Perrorprone {code}
> the {{ear}} project will not find the {{war}} anymore, because the war had:
> * Compile phase creating target/classes
> * package phase, which set projectArtifact.setFile() to the {{.war}} file.
> * verify phase, which set projectArtifact.setFile() back to
> {{target/classes}}.
> h2. Reproducible
> Always, see above.
> h2. Workarounds
> Do not execute verify+errorprone together with your main target phase and all
> reactor projects (e.g. including ear). But this will need two compile steps
> (one for packaging, anothero ne for error-prone).
> h2. Expected behaviour
> I can execute the maven-compiler-plugin with a compiler plugin like
> checkstyle in the verify phase without un-attaching any previous artifacts.
> At least as long as I compile into another directory.
> h2. Actual behaviour
> I cannot execute the compiler in the verify phase again using the
> {{maven-compiler-plugin}}, because it will reset my project artifacts.
>
> h2. errorprone configuration
> {code:java}
> <profile>
> <id>errorprone</id>
> <activation>
> <activeByDefault>false</activeByDefault>
> </activation>
> <build>
> <plugins>
> <plugin>
> <artifactId>maven-compiler-plugin</artifactId>
> <executions>
> <execution>
> <id>errorprone</id>
> <phase>verify</phase>
> <goals><goal>compile</goal></goals>
> <configuration>
> <showWarnings>true</showWarnings>
> <compilerArgs>
> <arg>-XDcompilePolicy=simple</arg>
> <arg>
> -Xplugin:ErrorProne
> ${plugin.errorprone.excluded.paths}
> -XepDisableWarningsInGeneratedCode
> ${plugin.errorprone.additional.checks}
> </arg>
> <arg>-d</arg>
> <arg>${project.build.directory}/classes-ep</arg>
> </compilerArgs>
> <annotationProcessorPaths>
> <path>
> <groupId>com.google.errorprone</groupId>
> <artifactId>error_prone_core</artifactId>
> <version>${dependency.errorprone.core.version}</version>
> </path>
> </annotationProcessorPaths>
> <useIncrementalCompilation>true</useIncrementalCompilation>
> </configuration>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
> </profile> {code}
> Note: I use incrementalCompilation=true which behaves like non-incremental
> compilation due to a bug which is open since ever.
> h2. Proposed sulutions
> Either create a new goal (compile-only) or provide a switch to not invoke
> [projectArtifact.setFile(outputdir)|[https://github.com/apache/maven-compiler-plugin/blob/master/src/main/java/org/apache/maven/plugin/compiler/CompilerMojo.java#L189]].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
