Update gradle, build process

[ultraq]

Just having a look through this projects build.gradle file and I can see a few things that could do with updating/modernizing:

• [x] Firstly, Gradle 4.0 was recently released with parallel downloading of artifacts and a whole heap of improvements since this was put together for version... errr, I forgot! (Should have used Gradle Wrapper on that old version!)
• [ ] There's also a fix for the hack/workaround added for the Jetty server since then.
• [x] The Jetty plugin isn't even a part of Gradle any more with devs being pointed in the direction of the Gretty plugin to get their webapps up and running quickly.
• [x] Use of the LessCssCompiler is probably a bit hax too now given that it is a dumb wrapper around the JS implementation of LessCSS, so it might be better to get Gradle to call to npm to do that job instead so that it's easier to keep that portion up to date.

[ultraq]

I've added the gradle wrapper, tied to the last 2.x version since that's what this project was originally built for. Will still need to take some time to do the above to clean things up and then need to update the gradle wrapper accordingly.

[danielfernandez]

So, do I need to do any changes or make sure that anything is configured in some specific way at the releases machine?

By the way, the releases machine is now an Ubuntu Server... somehow Amazon EC2 decided to kill our old releases CentOS machine in a way that it was not possible to start it again, complaining there was no /boot filesystem. I changed nothing so I assume it was some configuration update in the distribution (which was from the marketplace, not a standard EC2 one) that made this during a yum update. Then I also discovered that the EBS volumes that are created for AMIs from the Marketplace can only be mounted (which I needed to do for recovery) on machines instantiated from the same AMI, which is extremely inconvenient IMHO... so I finally decided to rebuild the base system on a standard, non-marketplace Ubuntu Server (which is working great and has newer versions of almost everything) and then recover all data and releases setup from the CentOS one by means of creating a temporary one and moving things from the non-working CentOS volume to the Ubuntu one.

[ultraq]

You shouldn't have to change anything for building docs right now. The idea behind the gradle wrapper is so that the version of gradle a project was built for can be invoked for builds no matter the actual version of gradle on the machine. It was something I noticed when I upgraded my own machine to 4.x and then suddenly couldn't build this project because so many things had changed since 2.x!

[danielfernandez]

Ok, so I assume the way to call the build here has changed to ./gradlew?

Also, remember to merge dev into master when finished. I'll probably have to release a new version today or tomorrow (docs can wait a bit, anyway) hot on the heels of Spring 5.0.0.RC3 which should be released today and just before Spring Boot 2.0.0.M3 which should use our new version. If you want me to use the new system for the docs of the new version (for which, anyway, I can wait a couple of days), then merge and tell me. If not... I'll just use the old mechanism.

[ultraq]

Ok, so I assume the way to call the build here has changed to ./gradlew?

Yup :)

I'll merge that part to master soon after writing this, but the other stuff in this issue that I wanted to do to get things working w/ newer versions of gradle, I won't get around to starting that for several days, so don't worry about waiting on those.

[ultraq]

Over 1 year later, finally upgraded! 😅 See #68 for details.