Update gradle from 5.3 to 6.1 in order to build with JDK 13 installed

[tebeco]

Summary of the changes (Less than 80 chars)

• Gradle 5.3 does not seem to be compliant with JDK 13
• Update Gradleto6.0`
• Was blocking local build of SignalR during another PR as i already had JDK 13 installed

Addresses #18287

I'm not familiar with etiher Java or Gradle, I tried to follow the documentation here and here

Here is what I ended up doing :

• Install gradle on my laptop / Update PATH (%GRADLE_HOME%=path/to/gradle and PATH = %GRADLE_HOME%\bin;%PATH%)
• Remove previous gradle files :

cd .\src\SignalR\clients\java\signalr\gradle
rm gradlew
rm gradlew.bat
rm -r .\wrapper

• regenerate scripts by running gradle wrapper --gradle-version=6.0.1 --distribution-type=bin (because previous distributionUrl was pointing to the bin one)
  FAILED :

❯ gradle wrapper --gradle-version=6.0.1 --distribution-type=bin

FAILURE: Build failed with an exception.

* Where:
Settings file 'C:\dev\github\tebeco\aspnetcore\src\SignalR\clients\java\signalr\settings.gradle' line: 6

* What went wrong:
A problem occurred evaluating settings 'signalr'.
> There is no feature named IMPROVED_POM_SUPPORT

• Removed enableFeaturePreview('IMPROVED_POM_SUPPORT') from settings.gradle :
  SUCESS :

❯ gradle wrapper --gradle-version=6.0.1 --distribution-type=bin

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.0/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 3s
1 actionable task: 1 executed

[analogrelay]

@tebeco thanks for this contribution! I want to raise one bit of complication here. Since binary files are very hard to diff, there are naturally some extra concerns when taking an external contribution containing them. You're a past contributor and I certainly don't expect anything suspect here, but we do need to take some extra care.

Also, we need to do some extra validation to ensure that this will work with the rest of our build system and produce correct packages (with accurate version numbers, etc.; since I know we've done some customization there).

Just raising those as points of information since they may add some delay to getting this in. Perhaps there's a way we can force the build to use a pre-13 version of the JDK even if 13 is installed as a stop-gap?

[tebeco]

@anurse
Not sure if it's easier for a Team Member, but if you get a fork/branch, i could create a fork/PR on a different remote without the binary
Then then team member then you could take care of adding that binary on his side

I'm fine with that

EDIT : no worry about waiting ;) thx a lot for the info ^^ it's nice to be informed about potential delay ;)

[tebeco]

Perhaps there's a way we can force the build to use a pre-13 version of the JDK even if 13 is installed as a stop-gap?

well why not, to be honest here is how i ended up seeing it:
I was bored to loose time when doing rebase reset --hard clean -fdx for all the required tooling pulled down but dotnet/arcade
basic idea was to see what tooling i could install globally to reduce that cost
the JDK is a perfect candidate ;) as it both take time / easy to install / version is stable

i just installed the latest JDK (from OpenJdk IIRC) nothing more

while trying to update msgpack i saw that i could not run build.cmd locally anymore and the error seemed to be from a cmd line breaking change
attempted to updatr gradle seemed to fix it and be compliant with JDK 11 (currently used in global.json for arcade)

i'm not a java developer so i probably can't help much more than this PR :D
just trying to see if it could be a long time fix to be honest ^^

[tebeco]

(rebased on master to kick the build)

[tebeco]

(thx for the bump to 6.1)

[BrennanConroy]

Thanks @tebeco !

[tebeco]

(Changed the title to 6.1 if anyone list the PR in github)