GradleWrapper
From APIDesign
| Line 1: | Line 1: | ||
For years [[I]] seem to have troubles adopting proper [[Gradle]]'s ''way of life'' as my [[Gradle]] post reveals in deep details. There are various reasons and every detail then counts. One can get quite sensitive even when seeing the '''gradlew''', '''gradlew.bat''' scripts and a [[JAR]] file called '''gradle-wrapper.jar''' in projects repositories. | For years [[I]] seem to have troubles adopting proper [[Gradle]]'s ''way of life'' as my [[Gradle]] post reveals in deep details. There are various reasons and every detail then counts. One can get quite sensitive even when seeing the '''gradlew''', '''gradlew.bat''' scripts and a [[JAR]] file called '''gradle-wrapper.jar''' in projects repositories. | ||
| - | However, in the context of [[APIDesign]] and particularly the [[PropertyFiles]] discussion, it is necessary to admit that using [[Gradle]] wrapper is a | + | However, in the context of [[APIDesign]] and particularly the [[PropertyFiles]] discussion, it is necessary to admit that using [[Gradle]] wrapper is a solid solution to address the (relatively frequent) incompatibilities between [[Gradle]] versions! The [[PropertyFiles]] essay concludes that ''When you design an [[API]] based on [[PropertyFiles]], don't forget to include a version identifier in it. Only then your [[API]] becomes ready for [[evolution]]''! |
By specifying version of [[Gradle]] to use in each project in '''gradle-wrapper.properties''' one follows the best practice advocated by me. Given relatively frequent incompatibilities between various versions of [[Gradle]] the conclusion must be strong: If you want to be sure your [[Gradle]] projects builds in a year or two, then: Whenever you create a [[Gradle]] project - make sure it contains the wrapper and exactly specifies the [[Gradle]] version! | By specifying version of [[Gradle]] to use in each project in '''gradle-wrapper.properties''' one follows the best practice advocated by me. Given relatively frequent incompatibilities between various versions of [[Gradle]] the conclusion must be strong: If you want to be sure your [[Gradle]] projects builds in a year or two, then: Whenever you create a [[Gradle]] project - make sure it contains the wrapper and exactly specifies the [[Gradle]] version! | ||
Revision as of 06:13, 22 June 2021
For years I seem to have troubles adopting proper Gradle's way of life as my Gradle post reveals in deep details. There are various reasons and every detail then counts. One can get quite sensitive even when seeing the gradlew, gradlew.bat scripts and a JAR file called gradle-wrapper.jar in projects repositories.
However, in the context of APIDesign and particularly the PropertyFiles discussion, it is necessary to admit that using Gradle wrapper is a solid solution to address the (relatively frequent) incompatibilities between Gradle versions! The PropertyFiles essay concludes that When you design an API based on PropertyFiles, don't forget to include a version identifier in it. Only then your API becomes ready for evolution!
By specifying version of Gradle to use in each project in gradle-wrapper.properties one follows the best practice advocated by me. Given relatively frequent incompatibilities between various versions of Gradle the conclusion must be strong: If you want to be sure your Gradle projects builds in a year or two, then: Whenever you create a Gradle project - make sure it contains the wrapper and exactly specifies the Gradle version!
Follow
