I understand that Gradle wrapper will be the preferred way for running Gradle (somewhat like daemon will be in 3.0). I’m starting a new project and want to use wrapper.
Main problem is that the client has specific non-functional requirement for the source repository – no jar files (or other non-specific binary formats are allowed) cannot be versioned.
How can I bootstrap wrapper for the build and download gradle-wrapper.jar initially? Is there any official solution for this? The manual states that “All of these files should be submitted to your version control system.” (including gradle-wrapper.jar).
There are several ways for doing this:
adding a manual step in building instructions
adding a separate script for downloading the distribution and extracting jar
modifying gradlew script itself to download & extract.
Manual step in instructions are cumbersome and scripting seems a bit hacky.
I’d ask the client for the reasons behind “no jars allowed”. I can see where this rule is coming from: An organization trying to stop people from checking in libraries (which is a good thing). But the gradle-wrapper.jar is a small tool that gives you great benefits.
[quote=“st_oehme, post:2, topic:18507, full:true”]
I’d ask the client for the reasons behind “no jars allowed”. I can see where this rule is coming from: An organization trying to stop people from checking in libraries (which is a good thing). But the gradle-wrapper.jar is a small tool that gives you great benefits.
[/quote]How often does gradle-wrapper.jar change? Ideally the gradle-wrapper.jar is added to repository once and it stays the same over the project life-cycle – that means that the old jar can deal with gradle infrastructure changes (download older version for gradle etc). Any comments on that side?
53 KB is indeed very small & that would be one argument to let gradle-wrapper.jar included into project. I’m starting a discussion with the client on the matter.
[quote=“ddimitrov, post:3, topic:18507, full:true”] @ilvez you can have small powershell script that downloads the wrapper jar if not present. On non-windows just use curl.[/quote] Yes, that is one of the three options from my initial script. But a custom script adds overall complexity to the project and has to be maintained etc, so this is not an ideal solution.
Yes, an old wrapper jar can download and start new Gradle versions. It changes very rarely. And it will only be updated if you explicitly run the gradle wrapper task again.
One way to bootstrap could be that locally installed Gradle would do it. Since the client has some version of Gradle installed locally, launching gradle wrapper would add gradle-wrapper.jar (including gradlew shell-scripts and excluding gradle/wrapper/gradle-wrapper.properties) and then continue building using wrapper. If using this method, is there a minimum version of Gradle, which should be used for initial gradle wrapper command?
Using this method, the problem is with gradle-wrapper.properties which will be overwritten. So if you want to specify for example distributionSha256Sum, it will be overwritten too.
When each developer/CI machine has their own Gradle version, I can guarantee that they will just run the build with that. And then you’ll get reports like “It doesn’t work on my machine”.
I’d just walk the client through it: From a productivity point of view, would they rather have:
a) A document that explains a weird setup process, just to comply with some overly strict rule
b) A developer setup that just works