[BEAM-5851] Update .gitignore file to remove IntelliJ generated gradle files

[ajamato]

Update .gitignore file to remove IntelliJ generated gradle files

---

Follow this checklist to help us incorporate your contribution quickly and easily:

• Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

It will help us expedite review of your Pull Request if you tag someone (e.g. @username) to look at it.

Post-Commit Tests Status (on master branch)

Lang	SDK	Apex	Dataflow	Flink	Gearpump	Samza	Spark
Go		---	---	---	---	---	---
Java
Python		---			---	---	---

[ajamato]

@lukecwik

[lukecwik]

R: @swegner

Intellij provides a button where the "full" version of Gradle can be fetched and used so that you get symbol lookups in Intellij when editing gradle files.

This .gitignore update will prevent "accidental" updates caused by users clicking that button in Intellij but will require devs who are specifically updating Gradle to use something like git add --force <FILE> to ensure it gets added.

The other thing is that our RAT check excludes everything in .gitignore which would mean that we would stop checking gradle-wrapper.properties/gradlew/gradlew.bat for license headers.

Do you think we should go with this or just be diligent during reviews to prevent accidental overwriting of these files?

Also, for users who want to click that button, they could be told to use a local .gitignore (https://medium.com/@peter_graham/how-to-create-a-local-gitignore-1b19f083492b) to avoid the annoying problem of git adding the changes to your commits.

[swegner]

Does IntelliJ add new wrapper files, or update existing ones? If it's adding new files, it would be nice if we could craft the exclusion here to only apply to the IntelliJ subdirectory and not the actual gradle wrappers.

[lukecwik]

It updates our existing ones.

[swegner]

I worry that the IntelliJ-based wrapper could have subtle differences that are incompatible with our build, and this will mask the local changes. If I let IntelliJ overwrite the wrapper and then my build starts failing, it will be very difficult to notice that the gradle wrapper is modified.

Is it important that we support this customization? Currently our IntelliJ documentation isn't very good, and it makes it much more difficult to document/support multiple customization. My preference is to pick one supported path and tell everybody to use it.

[ajamato]

Closing. Sc