Add Gradle wrapper files. Relates to #23

[aalmiray]

Signed OCA sent on March 15th, confirmation pending.

[brcolow]

This should also include changing .travis.yml and appveyor.yml to use the wrapper instead of installing and calling gradle.

[bourgesl]

Appveyor CI is still failing. See #24 for fixes

[bourgesl]

So changing appveyor.xml will be in conflict with #24 changes

[hendrikebbers]

LGTM

[kevinrushforth]

Upstream repo does not allow files with execute bit set, so will likely need to change this to something like:

sh ./gradlew ...

[kevinrushforth]

I like the idea of enabling gradlew. Since this is 3rd-party code, it will require approval before being committed upstream. I will do a quick check to see if this is likely to be approved.

[aalmiray]

Rebased this PR with the changes coming from #24 that were merged into master.
Also, gradlew no longer has the executable bit set.

[kevinrushforth]

I verified that we have the needed third-party approval to include gradle wrapper. As with other third-party code, I need to approve it (which I will) and we need to add a gradle.md file, which will go in a new gradle/legal directory. I will provide the contents of this file so you can add it into your PR.

[kevinrushforth]

This is being tracked in JBS by: https://bugs.openjdk.java.net/browse/JDK-8199841

[aalmiray]

Thanks @kevinrushforth!

[johanvos]

Any idea why appveyor fails on this PR?

[brcolow]

@johanvos The Appveyor build is failing because it is running against master and #32 was not merged to master. If you look at the Appveyor history: https://ci.appveyor.com/project/javafxports-github-bot/openjdk-jfx/history the PRs against the develop branch are successful. Why this PR is running against master when GitHub shows that it is trying to merge into develop I don't know. I only have experience with using Appveyor to run builds against master, so I am not sure how to tell Appveyor that PRs should be built against develop instead (and why aalmiray wants to merge 2 commits into javafxports:develop from aalmiray:gradle-wrapper is not enough for it to figure it out).

[johanvos]

I rebased the PR to develop, but maybe that didn't automatically re-run the appveyor tests.

[brcolow]

I see some mention of a "default branch" on the Appveyor docs..setting this to develop may alleviate having to manually rebase every PR and restart the builds manually.

[bourgesl]

Appveyor.xml seems complete and corresponding to PR#24, the only difference is gradleNew vs gradle !

Someone should read the complete log and maybe CLI args use an alternative syntax ?

[bourgesl]

@johanvos if you log in on appveyor with admin account, you can restart / cancel builds.
Who has admin rights on the repository ?
Maybe we should contact this person

[brcolow]

Appveyor.xml seems complete and corresponding to PR#24, the only difference is gradleNew vs gradle !

The reason has nothing to do with this PR, it is because Appveyor is building against master which doesn't have the fixes from #32 - Appveyor should always build PRs against the develop branch, which can be configured via Appveyor settings (not sure if there is a way to configure it using appveyor.yml or if it can only be done using web UI).

[aalmiray]

@brcolow would this mean merge #32 first then rebase this PR?

[bourgesl]

@johanvos could you change the default branch to develop on github settings ?

[brcolow]

@aalmiray #32 has already been merged into the develop branch. Appveyor just needs to properly build against that branch instead of master.

[javafxports-github-bot]

@bourgesl I've updated the default branch to develop.

[johanvos]

changing the default branch didn't trigger appveyor to run again.
@aalmiray Maybe you should make a very small change to the PR, so that tests will be run again?

[aalmiray]

Rebased gradle-wrapper branch against develop @ f79c724

[johanvos]

Checks passed, merging this.