build: update groovy wrapper

[jdrueckert]

What this PR does

Consume https://github.com/MovingBlocks/groovy-wrapper/releases/tag/v2.2.0 as documented in https://github.com/MovingBlocks/groovy-wrapper#to-use

ToDo before merge

• Figure out what I'm doing wrong and fixing it 🙄

Attempt 1:
What I did: Follow the "download, extract and place" approach (plus chmod +x).
What's going wrong: Locally running ./groovyw usage currently fails with /usr/bin/env: ‘sh\r’: No such file or directory.

Attempt 2:
What I did: Follow the "just grab and add" (copy + paste) approach.
What's going wrong: Locally running ./groovyw usage currently fails with

Caught: java.io.FileNotFoundException: /path/to/ts/workspace/usage (/path/to/ts/workspace/usage)
java.io.FileNotFoundException: /path/to/ts/workspace/usage (/path/to/ts/workspace/usage)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at org.gradle.wrapper.GroovyBootstrapMainStarter.start(GroovyBootstrapMainStarter.java:36)
	at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:103)
	at org.gradle.wrapper.GroovyWrapperMain.main(GroovyWrapperMain.java:60)

[BenjaminAmos]

Locally running ./groovyw usage currently fails with /usr/bin/env: ‘sh\r’: No such file or directory.

On Windows I got the following after cloning 51187f7:

Caught: java.io.FileNotFoundException: <workspace path>\Terasology\module (<workspace path>\Terasology\module)
java.io.FileNotFoundException: <workspace path>\Terasology\module (<workspace path>\Terasology\module)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at org.gradle.wrapper.GroovyBootstrapMainStarter.start(GroovyBootstrapMainStarter.java:36)
        at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:103)
        at org.gradle.wrapper.GroovyWrapperMain.main(GroovyWrapperMain.java:60)

[jdrueckert]

Locally running ./groovyw usage currently fails with /usr/bin/env: ‘sh\r’: No such file or directory.

On Windows I got the following after cloning 51187f7:

Caught: java.io.FileNotFoundException: <workspace path>\Terasology\module (<workspace path>\Terasology\module)
java.io.FileNotFoundException: <workspace path>\Terasology\module (<workspace path>\Terasology\module)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at org.gradle.wrapper.GroovyBootstrapMainStarter.start(GroovyBootstrapMainStarter.java:36)
        at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:103)
        at org.gradle.wrapper.GroovyWrapperMain.main(GroovyWrapperMain.java:60)

Yup, that's the same I get now too after copy/pasting the files rather than taking them from the extracted release zip... not entirely sure whether I'm doing something wrong or the documentation in the repo readme is out of date or whatever..

Interesting, though, that you got this already with my first attempt.

[jdrueckert]

@BenjaminAmos thanks for the hint, works now.

[Cervator]

Can validate that this works now. I submitted MovingBlocks/groovy-wrapper@e9ee667 to better document the customization of the Groovy Wrapper for a given project.

Still left out is another curiosity that might be a thing for another day: when the wrapper's base Gradle changes and the gradlew + gradlew.bat files get modified in theory those changes should be replicated in the groovyw + groovyw.bat files - but it seems unlikely that the thinner scope of simply running Groovy scripts will be affected every time, and this time it clearly isn't since, well, it works! I guess it sometimes is more about edge cases. Having upgraded the wrapper so rarely it just isn't something I've had much of a chance to think on, and really the number one thing is "Does it work" so ... it does!

Issue / change was resolved, dunno why GitHub doesn't recognize that