Réponses:
Avertissement: je travaille sur Bazel et je ne connais pas intimement Gradle. Cependant, un de mes collègues a rédigé une comparaison des deux systèmes, que je paraphraserai ici:
Bazel et Gradle mettent l'accent sur différents aspects de l'expérience de construction. Dans une certaine mesure, leurs priorités sont incompatibles - le désir de flexibilité et de non-intrusion de Gradle limite les restrictions qu'il peut imposer à la structure de construction, tandis que le désir de fiabilité et de performance de Bazel impose nécessairement des restrictions non négociables.
Gradle valorise les mêmes principes que Bazel, c'est-à-dire que l'équipe Gradle accorde une grande attention aux performances (builds incrémentiels, configuration et exécution parallélisées, le démon Gradle), à l'exactitude (vérification «à jour» basée sur le contenu) et à la reproductibilité (prise en charge riche de la syntaxe déclarative, du contrôle de version des dépendances, des dépendances explicitement déclarées). Et Bazel respecte le besoin de dispositions de projet flexibles.
La nuance est que Gradle veut promouvoir les bonnes pratiques tandis que Bazel veut l'exiger. Gradle vise un terrain d'entente entre l'expérience Ant (liberté de définir votre propre structure de projet avec des résultats incohérents) et l'expérience Maven (meilleures pratiques appliquées sans possibilité de faire varier les besoins du projet). Bazel pense qu'une prise en charge flexible des projets est possible sans sacrifier les solides garanties qui permettent ses puissants flux de travail.
Aucune des deux philosophies n'est plus «correcte» - l'outil qui convient le mieux à un projet dépend des valeurs de ce projet particulier.
Gradle est un système hautement flexible qui permet aux utilisateurs de créer facilement des flux de construction complets et fiables avec des contraintes minimales sur la façon dont ils organisent leurs projets. Il le fait en fournissant des blocs de construction puissants (par exemple, le suivi et la récupération automatiques des dépendances, la prise en charge des plugins étroitement intégrés) avec une interface de script générique, Turing-complète, qui peut combiner ces blocs comme les utilisateurs le souhaitent.
Gradle met l'accent sur les caractéristiques suivantes:
Bazel est né de la nécessité de créer des projets Google internes de manière fiable et efficace. Étant donné que l'environnement de développement de Google est inhabituellement vaste et complexe, Bazel offre des garanties exceptionnellement solides sur l'intégrité de ses versions et une surcharge de performances inhabituellement faible pour les atteindre.
Cela fournit une base pour des workflows de développement puissants construits autour de builds reproductibles, où une "build" devient une entité abstraite qui peut être référencée, répétée, transmise à différentes machines et transmise à des programmes et services arbitraires de sorte que chaque instance soit connue pour être exactement le même.
Bazel met l'accent sur les caractéristiques suivantes:
Alors que les liens d'articles ont tendance à mourir, voici un résumé des opinions de l'équipe Gradle sur Bazel (la plupart sont directement tirées de l'article, qui a été publié en mars 2015):
Il a été conçu pour résoudre un problème propre à Google; une base de code monolithique massive (des centaines de millions de LOC).
L'avantage de parallélisation que Bazel offre actuellement sera égalé par "notre nouvelle configuration et modèle de composants à venir" (gardez à l'esprit la date de l'article ici).
Bazel n'a pas de langage de construction déclaratif de haut niveau qui rend la construction facile à utiliser pour les développeurs. Chez Google, cela peut être compensé par une équipe de service spécialisée qui possède l'outil de création.
Bazel n'est pas conçu pour l'extensibilité (bien que l'équipe de développement de Bazel ait depuis contré cela en garantissant qu'elle travaille sur l'extensibilité).
La vitesse est optimisée autour de l'idée que toutes les dépendances transitives sont stockées dans un seul grand dépôt; toutes les bibliothèques et tous les outils sont archivés dans ce référentiel central. La plupart des entreprises ont des exigences de gestion des dépendances plus distribuées.
Bazel est uniquement * nix, il ne fonctionne pas sous Windows. Cela élimine un grand nombre d'entreprises potentielles.
Pas d'écosystème de plugins.
Gradle est principalement utilisé dans l'écosystème JVM (Java, Ggroovy, Scala, Kotlin ...). Si votre projet est dans ce domaine et que vous devez poser la question, Gradle ou Maven serait un meilleur choix. Pour dépanner une build Gradle, vous vous disputerez uniquement avec l'écosystème Java et JVM.
Bazel au cœur a la capacité de détecter les modifications incrémentielles (ainsi que le cache de build distribué) et vous permet de réagir, d'appliquer des plugins / règles pour réaliser des builds incrémentiels. Pour configurer et maintenir cela, il fallait un peu de connaissances en CPP, Java et Python (Skylark) et les connaissances de l'administrateur système également. Encore une fois, si vous devez poser la question, je pense que Gradle ou Maven serait un investissement moins cher. Avec Bazel, vous pouvez créer toutes les langues, de la manière que vous définissez, plus de puissance, mais à un coût.