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 many projects repositories. Binaries in a [[Git]]! Is that supposed to be a proper design? | 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 many projects repositories. Binaries in a [[Git]]! Is that supposed to be a proper design? | ||
| - | 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]]''! | + | 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|files]] (like '''build.gradle''' & co.), don't forget to include a version identifier in it. Only then your [[API]] becomes ready for [[evolution]]''! |
By including '''gradle-wrapper.properties''' in each project and specifying the '''right''' version of [[Gradle]] to use one follows the best practice advocated by [[TheAPIBook]]. Let's make the conclusion clear: If you want to be sure your [[Gradle]] projects build in a year or two (when the [[coolness]] majority switches to new version of [[Gradle]]), then always use the [[GradleWrapper]] and exactly specify the [[Gradle]] version! | By including '''gradle-wrapper.properties''' in each project and specifying the '''right''' version of [[Gradle]] to use one follows the best practice advocated by [[TheAPIBook]]. Let's make the conclusion clear: If you want to be sure your [[Gradle]] projects build in a year or two (when the [[coolness]] majority switches to new version of [[Gradle]]), then always use the [[GradleWrapper]] and exactly specify the [[Gradle]] version! | ||
Revision as of 06:21, 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 many projects repositories. Binaries in a Git! Is that supposed to be a proper design?
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 files (like build.gradle & co.), don't forget to include a version identifier in it. Only then your API becomes ready for evolution!
By including gradle-wrapper.properties in each project and specifying the right version of Gradle to use one follows the best practice advocated by TheAPIBook. Let's make the conclusion clear: If you want to be sure your Gradle projects build in a year or two (when the coolness majority switches to new version of Gradle), then always use the GradleWrapper and exactly specify the Gradle version!
Follow
