Skip to content
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

fix: profile for jdk17 compiler arguments #1775

Merged

Conversation

burkedavison
Copy link
Member

@burkedavison burkedavison commented Apr 27, 2023

JDK17 profile was not correctly applying the configuration due to an invalid artifactId.

On fixing the artifactId, the multi-line argument was causing javac to throw an exception, so these arguments have been
split into dedicated <arg> entries
...reverted to the single-line argument it was prior to the introduction of the profile error.

mvn compile -X now shows:

compilerArgs = [-XDcompilePolicy=simple, -Xplugin:ErrorProne -Xep:UnicodeInCode:OFF, -parameters, -J--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED, ...

@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

@breun
Copy link
Contributor

breun commented Apr 28, 2023

Shouldn’t each -X argument have its own <arg> entry?

<arg>-Xplugin:ErrorProne</arg>
<arg>-Xep:UnicodeInCode:OFF</arg>
<arg>-Xep:CanIgnoreReturnValue:OFF</arg>

@burkedavison
Copy link
Member Author

@breun : https://errorprone.info/docs/flags in the Maven section at the bottom shows one line.

Splitting into multiples like you suggest was how the first commit of this PR attempted to do it, but this resulted in a build failure so I went with one line.

@breun
Copy link
Contributor

breun commented Apr 29, 2023

I see the ErrorProne docs indeed say "The flags must be appended to the arg entry containing -Xplugin:ErrorProne." I don't really understand why, but alright. :)

@JoeWang1127
Copy link
Contributor

Just curious, why -Xep:CanIgnoreReturnValue:OFF is removed?

@burkedavison
Copy link
Member Author

It was causing a compiler exception. This commit 3916323 is when it was removed in this PR. Looking at the builds in the prior commit https://github.com/GoogleCloudPlatform/spring-cloud-gcp/actions/runs/4821699659/jobs/8587923313 shows what that looked like.

Running locally produces:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile (default-compile) on project spring-cloud-gcp-data-datastore: Compilation failure -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile (default-compile) on project spring-cloud-gcp-data-datastore: Compilation failure
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:375)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:351)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:171)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:163)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call (MultiThreadedBuilder.java:210)
    at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call (MultiThreadedBuilder.java:195)
    at java.util.concurrent.FutureTask.run (FutureTask.java:264)
    at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:539)
    at java.util.concurrent.FutureTask.run (FutureTask.java:264)
    at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1136)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:635)
    at java.lang.Thread.run (Thread.java:833)
Caused by: org.apache.maven.plugin.compiler.CompilationFailureException: Compilation failure
    at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute (AbstractCompilerMojo.java:1314)
    at org.apache.maven.plugin.compiler.CompilerMojo.execute (CompilerMojo.java:198)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:370)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:351)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:171)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:163)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call (MultiThreadedBuilder.java:210)
    at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call (MultiThreadedBuilder.java:195)
    at java.util.concurrent.FutureTask.run (FutureTask.java:264)
    at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:539)
    at java.util.concurrent.FutureTask.run (FutureTask.java:264)
    at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1136)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:635)
    at java.lang.Thread.run (Thread.java:833)

And perhaps most importantly: this setting is disabling a check that doesn't cause a failure when it's enabled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants