-
Notifications
You must be signed in to change notification settings - Fork 1
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
Enforce formatting with spotless #23
Conversation
Thanks for proposing the formatting enforcement! My responses on the decisions to make: Re-ordering of poms : Sounds reasonable to me to unify POMs as well. Are there any drawbacks I don't see? Tabs/spaces: As you know, I am in favor of tabs, but spaces are also fine for me. I think that currently most of the files are formatted with tabs, but that might not be an argument in favor of one or the other Formatting guidelines: The ones from JPlag are fine for me. We should just change the name of the formatter as it still contains "JPlag" 😉 Check during every build: Couldn't we put the spotless plugin into a Maven profile, which you can activate locally on demand with something like |
Only that the initial spotless formatting commit of each repo might change each pom file a lot. After that, they all will be consistently ordered though.
Will do! 😄
Actually, by default one can run
This is the case because people that are less familiar with the project might not run spotless before committing or pushing. |
Pom reordering: 👍🏼 tabs / spaces: I am used to spaces but as the IDE should do it automatically when integrating the provided formatter (if I understand correctly?) I don't really care. I couldn't find any strong arguments with a short research for any side. Formatting guidelines: Fine with provided ones Maven build: I would separate functionality and formatting so don't check formatting in the default build. Having some spotless issue fix commits won't hurt anyone (and contributors should learn this after once mistakenly commit wrong formatted) but running the format checks by default in every local build is an unnecessary overhead. |
Pom reordering: 👍 Maven build: I am fine with both. I would also be fine with spotless checks by default (which we might even allow to disable with a specific profile). What happens if spotless checks fail? Does the complete build fail or does it only provide warnings (or can we configure that)? Having checks with warnings in the default build would be the best option in my opinion. |
By default it fails the build. An example can be seen here. |
Thank you for the effort! POM re-ordering: 👍 Tabs/spaces: No strong opinion here. Personally, I would prefer tabs. Formatting guidelines: The ones from JPlag are also fine with me 👍 Maven build: I would include spotless in the default maven build, but only issue warnings (i.e., no build failure if spotless checks fail). In the GitHub action workflow the build should fail if any spotless checks fail. Otherwise, warnings will just be ignored. Like Jan, I don't see much harm in the occasional spotless issue fix commits. |
To my knowledge, it is not possible to configure spotless to only show the issues as warnings. This means we either check with spotless during every mvn build and the build fails if there are style issues. Or we only check the style for PRs via a workflow and we ourselves need to call spotless explicitly during development if we want to know if there are issues. |
Revert Spotless (pull request #23)
This is an initial PR to support formatting/code style with spotless thus addressing vitruv-tools/Vitruv#495 and vitruv-tools/Vitruv#497. It allows to check these guidelines via
mvn spotless:check
and apply them automatically withmvn spotless:apply
.It includes:
Decisions to make:
Left to do:
spotless:check
to the reposEDIT: Note that this PR does not yet include workflows to run spotless checks on incoming PRs. Thus, we can merge this PR and then add the missing workflows whenever we want to start enforcing these style guidelines.