Gradle Wrapper: Support init.d zip

[Tanemahuta]

Expected Behavior

• define a property initscriptUrl which may either be a .gradle, .gradle.kts or .zip containing init scripts
• define an optional property initscriptPath to which the scripts should be downloaded/unzipped to
• args for BootstrapMainStarter should include the init scripts

Current Behavior (optional)

No response

Context

When using the wrapper in an enterprise environment (e.g. with mirrors for repositories), it would be nice to share some of the essential settings with all users. IMHO the wrapper would be the best point to do so.

I know you can build your own wrapper distribution zip and include the init scripts there, but this means maintaining a wrapper for each init scripts distribution, while the wrapper code is not in itself tied to the init script.

[ljacomet]

From a user perspective, maintaining a custom initscriptUrl or pointing to a custom distribution is the same: change one URL.

I don't think providing one more way to handle such a scenario would help Gradle users.

Can you describe more why you think going with a custom distribution is not OK?

[Tanemahuta]

There is a difference in maintaining init-scripts versus maintaining a distribution. In order to maintain the latter, someone has to download, extract the original distribution zip and repackage the zipfile including the init-scripts.

In order to support multiple versions, this process has to be repeated for each version (I know, this is easy to automate).

In case a fix or feature is implemented in the buildscripts, the wrapper dist artifact has to be recreated and thus the version of the build-scripts have to be included.

I personally see this as an unnecessary overhead (also in terms of storage), while also breaking loose coupling via component versions (gradle version as dist, init-scripts version).

I am willing to refactor the wrapper code, implement the behaviour and do a pull request, if that would help the cause.

[ov7a]

There are many ways to achieve what you want - custom distribution, custom wrapper, custom wrapper script (gradlew), user home dir management, etc. Given the scope of the changes and the use case, we don't think that this would be a good addition to Gradle - it would only add more complexity to it.

Based on that, closing this, sorry.

[Tanemahuta]

Very unfortunate.