-
Notifications
You must be signed in to change notification settings - Fork 55
SpotlessApply uses by default the Java formatter #1243
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
Conversation
Generate changelog in
|
|
||
} | ||
|
||
private static Iterable<File> getBuildPluginClasspathInjector() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should I move this to https://github.com/palantir/gradle-plugin-testing ? gradle-jdks needs to do the same thing in order to run on multiple Java versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand what it's supposed to do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose what I don't understand is why you need this at all? I thought nebula does this for you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to test how the task works against Java 17 and Java 21. So, I am using the gradle-jdks automanagement workflow
to set-up the JDKs but then I also need to run ./gradlew
instead of the classic nebula runTask
. When using nebula runTask
the plugin is injected automatically, but now I need to set it on my own. This is what getBuildPluginClasspathInjector
does - it adds the files of the plugin to the test classpath.
I have the same setup in gradle-jdks
for tests - so I was wondering if it makes sense to move this logic in the testing plugin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, I thought the tooling api invoked gradlew, interesting!
you could move it to gradle-plugin-testing, it's a bit niche, but I don't see why not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a nicer way to do this, is probably to reuse some of the stuff in Nebula, it makes your life a lot easier I think:
- Use
ClasspathAddingInitScriptBuilder
to write the classpath in an init script form - include the init script when running
gradlew
. i.e../gradlew <task> -i init-script
I think the current approach - I also mentioned something similar in the testing plugin PRs - detracts from the test by adding a bunch of cruft that's not actually important to know for the test, but is unfortunately required for the test to pass.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It also means, that you can hide all of this behind a runGradlew
method and not have to pollute the test with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An aside: I think you could probably ship this method + runTasksViaGradlew
into gradle-testing-plugin or a new thing. It'd just look very similar to IntegrationSpec
or something.
…antir-java-format into cr/spotless-uses-java-if-21
README.md
Outdated
switched to a native image for the formatter. The startup time for the native image esp. in Intellij is >10x faster than | ||
spinning up a new process that does the formatting. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a tad confusing, in both cases you're spinning up a new process.
Correct me if I've misunderstood, but I believe you want something along the lines of:
is >10x faster than spinning up a new JVM process that does the formatting
?
README.md
Outdated
switched to a native image for the formatter. The startup time for the native image esp. in Intellij is >10x faster than | ||
spinning up a new process that does the formatting. | ||
However, the throughput of running the native image for a large set of files (eg. running `./gradlew spotlessApply`) is | ||
considerably slower (eg. 30ms using the Java implementation vs 1m20s using the native image implementation). Therefore, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
30 milliseconds vs 1 minute 20s?
""".replace("EXTRA_CONFIGURATION", extraDependencies).stripIndent() | ||
|
||
javaVersions { | ||
libraryTarget = JAVA_VERSION |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we just string interpolate here?
File initScript = new File(projectDir, INIT_FILE_NAME) | ||
ClasspathAddingInitScriptBuilder.build(initScript, getBuildPluginClasspathInjector().toList()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should move into runGradlewTasks
then you don't even need to have a constant. It's kinda similar to how the nebula thing does it, doesn't necessarily have to be a temp file, but I don't think it's anything specific to this particular test unlike CLASSPATH_FILE
and NATIVE_CONFIG
etc.
Invalidated by push of 113ee73
👍 |
Released 2.67.0 |
Before this PR
The throughput for formatting big repos is decreased by using the native image (CE edition) - see internal metrics doc here and comment here
java-based implementation 32 secs vs native-image implementation 1min 20sec.
Even though spotlessApply is incremental and cacheable, in case the task cannot run incrementally, the performance is not good.
After this PR
When running
spotlessApply
tasks only (to format full projects), we will switch to using:formatDiff/Intellij will still use the native image formatter by default - the perf for running on a few files is better with native-image vs Java-based implementations.
==COMMIT_MSG==
SpotlessApply uses by default the Java formatter
==COMMIT_MSG==
Possible downsides?