-
Notifications
You must be signed in to change notification settings - Fork 52
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
[BUILD] Check java formatting in Travis CI #313
Conversation
682f86d
to
dd8a976
Compare
local jar_name=$1 | ||
|
||
echo 'Checking format' | ||
java -jar "$jar_name" --dry-run --set-exit-if-changed **/*.java |
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.
If just check changed files is enough you could maybe use the file list of git diff master --name-only --diff-filter=d
.
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 think it is necessary to optimize this for now. A basic setup is enough for the beginning. If it slows down the builds to much, we can improve it.
(When creating the git diffs, you would have to you the correct base branch to compare against as not all builds are against the master. An easy example are builds for stacked PRs. Kelvin mentioned that this would be possible through travis variables, but I am not certain we really need it for now.)
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.
Ok.
I don't think it's a problem to always diff against the master, because yes in a Stacked PR you would check all PRs/commits in the chain but that is not a real problem isn't 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.
Looks good to me (except for using "Formatter.jar" directly, which Stefan already mentioned).
I would suggest to also include the formatting in this PR as a separate commit. But this can be done shortly before merging it (after the gradle stuff).
dd8a976
to
ced4a5c
Compare
* Introduced Formatting stage in travis * Created script for downloading and executing the google java formatter
ced4a5c
to
57f7bfb
Compare
@tobous Added corresponding formatting commit. |
How about also removing the old fotmatting Config files as they are no longer useful and could give users the impression that they are using the correct formatting? |
* Remove old IntelliJ formatting configs * Remove old eclipse formatting profile
c7515a1
to
b965321
Compare
I removed IntelliJ code style settings and the eclipse formatting profile. I did not remove the eclipse clean-up profile, because it configures things like (remove unused imports etc.) and not 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.
.settings/org.eclipse.jdt.ui.prefs
Files still mention a Saros Formater, but the rest looks good to me
The files in the "patches" folder were always excluded from any auto-format commits. Those are "original" pieces of other projects' code with minor amendments. Auto-formatting these makes it way harder to see the actual "patch". |
the google java formatter