-
Notifications
You must be signed in to change notification settings - Fork 493
centralize spotless config
#2741
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
| } | ||
| groovyGradle { | ||
| target '*.gradle' | ||
| target '*.gradle', 'gradle/*.gradle' |
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.
do we really need both ?
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.
Yeah, I believe so, because:
*.gradlemeans "search for all files ending with.gradlein the project directory"gradle/*.gradlemeans "search for all files ending with.gradlein thegradlesubdirectory"
The alternative, **/*.gradle, which IIRC means "search for all files ending with .gradle in the project directory and every sub-directory", is slower than necessary because it searches through more things.
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.
The alternative,
**/*.gradle, which IIRC means "search for all files ending with.gradlein the project directory and every sub-directory", is slower than necessary because it searches through more things.
Thank you yes, was thinking about double as well, good layout.
slower than necessary
imho, code (simplicity, accessibility) over cpu.
| target '*.gradle', 'gradle/*.gradle' | |
| target '**.gradle' |
spotless/gradle/rewrite.gradle
Line 13 in 27f4e5c
'**lib-extra/build.gradle',
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 you post here how long it takes to run Spotless before and after the change? If there's no noticeable difference and Ned is happy with it, then I'll accept 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.
Yes, will try.
IMO, Ned is pretty straightforward, having a good “doesn’t matter” mentality. Especially when it comes to chasing seconds around. IMO, it won’t take much longer, but I’m interested too, lets see.
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.
Agreed that we do need both. And it's surprising how bad the performance of target '**/*.gradle' is. We used to have it, I think the problem is that it gobbles the .git folder too sometimes. Anyway, PR looked good as-is, merged.
| apply from: rootProject.file('gradle/rewrite.gradle') | ||
| apply from: rootProject.file('gradle/spotless-freshmark.gradle') | ||
|
|
||
| spotless { |
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.
lets avoid the redundancy if possible and follow:
- separation of control instead of
- duplication of control
| @@ -1,5 +1,4 @@ | |||
| apply plugin: 'org.openrewrite.rewrite' | |||
|
|
|||
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.
lets use block like done in spotless config.
0beb2c7 to
01aff7f
Compare
Signed-off-by: Vincent Potucek <[email protected]>
01aff7f to
df4157b
Compare
Please DO NOT FORCE PUSH. Don't worry about messy history, it's easier to do code review if we can tell what happened after the review, and force pushing breaks that.
Please make sure that your PR allows edits from maintainers. Sometimes it's faster for us to just fix something than it is to describe how to fix it.
After creating the PR, please add a commit that adds a bullet-point under the
[Unreleased]section of CHANGES.md, plugin-gradle/CHANGES.md, and plugin-maven/CHANGES.md which includes:If your change only affects a build plugin, and not the lib, then you only need to update the
plugin-foo/CHANGES.mdfor that plugin.If your change affects lib in an end-user-visible way (fixing a bug, updating a version) then you need to update
CHANGES.mdfor both the lib and all build plugins. Users of a build plugin shouldn't have to refer to lib to see changes that affect them.This makes it easier for the maintainers to quickly release your changes :)