Pourquoi le Gradle Wrapper devrait-il être engagé dans VCS?

De la documentation de Gradle: https://docs.gradle.org/current/dsl/org.gradle.api.tasks.wrapper.Wrapper.html

Les scripts générés par cette tâche sont destinés à être validés dans votre système de contrôle de version. Cette tâche génère également un petit fichier JAR d'amorçage gradle-wrapper.jar et un fichier de propriétés qui doivent également être validés dans votre VCS. Les scripts délèguent à ce JAR.

De: Que ne devrait PAS être sous le contrôle de la source?

Je pense Generated filesne devrait pas être dans le VCS.

Quand gradlewet quand sont -ils gradle/gradle-wrapper.jarnécessaires?

Pourquoi ne pas stocker un gradle versiondans le build.gradlefichier?

Parce que tout l'intérêt du wrapper gradle est de pouvoir, sans avoir jamais installé gradle, et sans même savoir comment il fonctionne, où le télécharger, quelle version, pour cloner le projet à partir du VCS, d'exécuter le script gradlew il contient et pour générer le projet sans aucune étape supplémentaire.

Si tout ce que vous aviez était un numéro de version gradle dans un fichier build.gradle, vous auriez besoin d'un README expliquant à tout le monde que la version gradle X doit être téléchargée à partir de l'URL Y et installée, et vous devriez le faire à chaque fois que la version est incrémentée.

Parce que tout l'intérêt du wrapper gradle est de pouvoir, sans avoir jamais installé gradle

Le même argument vaut pour le JDK, voulez-vous le valider également? Engagez-vous également toutes vos bibliothèques dépendantes?

Les dépendances doivent être mises à niveau en permanence à mesure que de nouvelles versions sont publiées. Pour obtenir des correctifs de sécurité et d'autres bogues. Et parce que si vous arrivez trop loin derrière, il peut être très fastidieux de se mettre à jour.

Si l'encapsuleur gradle est incrémenté à chaque nouvelle version et qu'il est validé, le dépôt deviendra très volumineux. Le problème est évident lorsque vous travaillez avec un VCS distribué où un clone téléchargera toutes les versions de tout.

, et sans même savoir comment ça marche

Créez un script de construction qui télécharge le wrapper et l'utilise pour créer. Tout le monde n'a pas besoin de savoir comment fonctionne le script, ils doivent accepter que le projet est construit en l'exécutant.

, où le télécharger, de quelle version

task wrapper(type: Wrapper) {
 gradleVersion = 'X.X' 
}

Puis

gradle wrapper

Pour télécharger la bonne version.

, pour cloner le projet à partir du VCS, pour exécuter le script gradlew qu'il contient et pour construire le projet sans aucune étape supplémentaire.

Résolu par les étapes ci-dessus. Le téléchargement du wrapper gradle n'est pas différent du téléchargement d'autres dépendances. Le script pourrait être intelligent pour vérifier tout wrapper de gradle actuel et le télécharger uniquement s'il existe une nouvelle version.

Si le développeur n'a jamais utilisé Gradle auparavant et ne sait peut-être pas que le projet est construit avec Gradle. Ensuite, il est plus évident d'exécuter un "build.sh" par rapport à l'exécution de "gradlew build".

Si tout ce que vous aviez était un numéro de version gradle dans un fichier build.gradle, vous auriez besoin d'un README expliquant à tout le monde que la version gradle X doit être téléchargée à partir de l'URL Y et installée,

Non, vous n’avez pas besoin d’un fichier README. Vous pourriez en avoir un, mais nous sommes des développeurs et nous devons automatiser autant que possible. Créer un script est mieux.

et vous devrez le faire à chaque fois que la version est incrémentée.

Si les développeurs conviennent que le processus correct consiste à:

1. Cloner le repo
2. Exécuter le script de construction

Ensuite, la mise à niveau vers le dernier wrapper gradle ne pose aucun problème. Si la version est incrémentée depuis la dernière exécution, le script peut télécharger la nouvelle version.

Je voudrais recommander une approche simple.

Dans le fichier README de votre projet, indiquez qu'une étape d'installation est requise, à savoir:

gradle wrapper --gradle-version 3.3

Cela fonctionne avec Gradle 2.4 ou supérieur. Cela crée un wrapper sans nécessiter l'ajout d'une tâche dédiée à "build.gradle".

Avec cette option, ignorez (ne archivez pas) ces fichiers / dossiers pour le contrôle de version:

• ./gradle
• Gradlew
• gradlew.bat

Le principal avantage est que vous n'avez pas à archiver un fichier téléchargé dans le contrôle de code source. Cela coûte une étape supplémentaire lors de l'installation. Je pense que ça vaut le coup.

Qu'est-ce que le «projet»?

Il existe peut-être une définition technique de cet idiome qui exclut les scripts de construction. Mais si nous acceptons cette définition, alors nous devons dire que votre "projet" n'est pas tout ce dont vous avez besoin pour versionner!

Mais si nous disons "votre projet", c'est tout ce que vous avez fait . Ensuite, nous pouvons dire que vous devez l'inclure et seulement cela dans VCS.

Ceci est très théorique et peut-être pas pratique dans le cas de nos travaux de développement. Nous le changeons donc en " votre projet est tous les fichiers (ou dossiers) dont vous avez besoin pour les éditer directement ".

^{«directement» signifie «pas indirectement» et «indirectement» signifie en éditant un autre fichier et un effet sera alors reflété dans ce fichier .}

Nous arrivons donc à la même chose qu'OP a dit (et est dit ici ):

Je pense que les fichiers générés ne devraient pas être dans le VCS.

Oui. Parce que vous ne les avez pas créés. Ils ne font donc pas partie de "votre projet" selon la deuxième définition.

Quel est le résultat de ces fichiers:

• build.gradle : Oui. Nous devons le modifier. Nos travaux doivent être versionnés.

  Remarque: il n'y a aucune différence là où vous le modifiez. Que ce soit dans votre environnement d'éditeur de texte ou dans l' environnement GUI de la structure de projet . Quoi qu'il en soit, vous le faites directement !

• gradle-wrapper.properties : Oui. Nous devons au moins déterminer la version de Gradle dans ce fichier.

• gradle-wrapper.jar et gradlew [.bat] : Je ne les ai pas créés ou modifiés dans aucun de mes travaux de développement, jusqu'à ce moment! Donc la réponse est non". Si vous l'avez fait, la réponse est "Oui" à propos de vous à ce travail (et du même fichier que vous avez édité).

La note importante concernant le dernier cas est que l'utilisateur qui clone votre dépôt doit exécuter cette commande sur les dépôts<root-directory> pour générer automatiquement des fichiers wrapper:

> gradle wrapper --gradle-version=$v --distribution-type=$distType

$vet $distTypesont déterminés à partir de gradle-wrapper.properties :

distributionUrl=https\://services.gradle.org/distributions/gradle-{$v}-{$distType}.zip

Voir https://gradle.org/install/ pour plus d'informations.

gradlel'exécutable est bin/gradle[.bat]en distribution locale. Il n'est pas nécessaire que la distribution locale soit la même que celle déterminée dans le repo. Une fois les fichiers wrapper créés, vous gradlew[.bat]pouvez télécharger automatiquement la distribution Gradle déterminée (si elle n'existe pas localement). Ensuite, il / elle doit probablement régénérer les fichiers wrapper en utilisant le nouvel gradleexécutable (dans la distribution téléchargée) en utilisant les instructions ci-dessus.

Remarque: Dans les instructions ci-dessus, on suppose que l'utilisateur a au moins une distribution Gradle localement (par exemple ~/.gradle/wrapper/dists/gradle-4.10-bin/bg6py687nqv2mbe6e1hdtk57h/gradle-4.10). Il couvre presque tous les cas réels. Mais que se passe-t-il si l'utilisateur n'a déjà aucune distribution?

Il / Elle peut le télécharger manuellement en utilisant l'URL dans le .propertiesfichier. Mais s'il / elle n'a pas le localiser dans le chemin que l' emballage prévu, l' emballage sera le télécharger à nouveau! Le chemin attendu est complètement prévisible mais est hors du sujet (voir ici pour la partie la plus complexe).

Il existe également des moyens plus faciles (mais sales). Par exemple, il / elle peut copier des fichiers wrapper (à l'exception du .propertiesfichier) de n'importe quel autre référentiel local / distant vers son référentiel, puis les exécuter gradlewsur son référentiel. Il téléchargera automatiquement la distribution appropriée.

Selon la documentation de Gradle , l'ajout gradle-wrapper.jarà VCS est attendu car rendre Gradle Wrapper disponible pour les développeurs fait partie de l'approche Gradle:

Pour rendre les fichiers Wrapper disponibles à d'autres développeurs et environnements d'exécution, vous devrez les archiver dans le contrôle de version. Tous les fichiers Wrapper, y compris le fichier JAR, sont de très petite taille. L'ajout du fichier JAR au contrôle de version est attendu. Certaines organisations n'autorisent pas les projets à soumettre des fichiers binaires au contrôle de version. Pour le moment, il n'y a pas d'alternative à l'approche.

Ancienne question, réponse fraîche. Si vous ne mettez pas à jour gradle souvent (la plupart d'entre nous ne le font pas), il est préférable de le valider dans VCS. Et la raison principale pour moi est d'augmenter la vitesse de construction sur le serveur CI. De nos jours, la plupart des projets sont construits et installés par des serveurs CI, une instance de serveur différente à chaque fois.

Si vous ne le validez pas, le serveur CI téléchargera un fichier JAR pour chaque build et cela augmentera considérablement le temps de build. Il existe d'autres moyens de gérer ce problème, mais je trouve que celui-ci est le plus simple à maintenir.