- Un outil de build multilangage rapide et extensible prenant en charge Java, Scala et Kotlin
- Les outils de build JVM sont souvent jugés lents et confus, mais Mill cherche à exploiter au maximum les performances et la facilité d’utilisation de la JVM
- Il peut compiler le même codebase Java 5 à 10 fois plus vite que Maven et 2 à 4 fois plus vite que Gradle
- Le langage de configuration typé et le graphe de tâches immuable permettent de garder les builds propres et faciles à comprendre
- Il passe bien à l’échelle, d’un petit projet à module unique jusqu’à un grand monorepo comptant des centaines de modules
Les avantages de Mill
- Performance : le graphe de build de Mill met automatiquement en cache et parallélise les tâches de build afin de garder le workflow rapide et réactif. Il fournit des outils pour identifier et résoudre les goulots d’étranglement du build tout en ajoutant un minimum d’overhead à la logique nécessaire pour compiler le projet
- Maintenabilité : au-delà de YAML et de Bash, il permet d’écrire la configuration et la logique de personnalisation sous forme de code concis et vérifié par les types, en utilisant un arbre de modules immuable et un graphe de tâches immuable. Cela aide à détecter les problèmes de configuration plus tôt et permet à l’IDE (IntelliJ ou VSCode) de mieux comprendre les builds Mill que ceux d’autres systèmes de build
- Flexibilité : les tâches et modules de Mill permettent aussi bien d’ajouter une simple étape de build que de gérer une chaîne d’outils de langage complète. Vous pouvez importer n’importe quelle bibliothèque JVM dans le build, utiliser le riche écosystème de plugins Mill tiers ou écrire vous-même un plugin puis le publier sur Maven Central pour que d’autres puissent l’utiliser
Mill vs les autres outils de build
- Mill reprend des idées d’autres outils comme Maven, Gradle et Bazel, tout en cherchant à retenir les points forts de chacun et à améliorer leurs faiblesses
- Mill vs Maven
- Mill reprend l’innovation de Maven consistant à fournir de bons réglages par défaut
- Le
JavaModule intégré de Mill suit l’approche « convention plutôt que configuration » de Maven, ce qui permet aux petits projets Mill de démarrer avec un effort minimal, tandis que les projets Mill plus grands conservent une structure cohérente fondée sur ces valeurs par défaut
- Mill met automatiquement les builds en cache et les parallélise pour offrir un gain de vitesse de 3 à 10 fois
- Cela vaut non seulement pour les tâches intégrées fournies avec Mill, mais aussi pour les tâches ou modules personnalisés. Cela aide à maximiser l’agilité du workflow de build en ligne de commande et à préserver la productivité, en particulier sur les codebases plus volumineux où les builds ont tendance à ralentir. Là où le workflow « clean install » de Maven peut prendre plus d’une minute, Mill peut n’en demander que quelques secondes
- Mill permet de personnaliser l’outil de build bien plus facilement que Maven
- Un projet finit généralement par aller au-delà de la simple compilation d’un seul langage. Il faut de la génération de code personnalisée, des workflows de linting, des intégrations d’outils, des artefacts de sortie ou la prise en charge de langages supplémentaires. L’extensibilité de Mill et son expérience IDE permettent de le faire directement, facilement et en toute sécurité grâce à du code vérifié par les types et à des tâches sandboxées
- Mill vs Gradle
- Mill reprend la concision et l’extensibilité de Gradle
- Au lieu de pages de XML verbeux, chaque ligne d’un build Mill a du sens. Par exemple, l’ajout d’une dépendance tient sur une ligne dans Mill, comme dans Gradle, contrairement aux 5 lignes de déclaration
<dependency> que l’on trouve dans Maven. Comme avec Gradle, l’utilisateur final peut facilement personnaliser le build selon ses besoins précis sans devoir passer par le processus d’écriture de plugin
- Mill peut être 2 à 3 fois plus rapide que Gradle
- Mill comme Gradle mettent automatiquement les builds en cache et les parallélisent, mais Mill le fait avec beaucoup moins d’overhead fixe. Cela signifie moins de temps passé à attendre l’outil de build et plus de temps pour ce qui compte vraiment dans le projet
- Mill applique les bonnes pratiques par défaut
- Chaque partie d’un build Mill est mise en cache et incrémentale par défaut. Chaque tâche Mill écrit sa sortie dans un emplacement standard. Toutes les dépendances entre tâches sont capturées automatiquement sans annotations manuelles. Là où Gradle demande des efforts et une expertise considérables pour comprendre le build et le configurer correctement, l’excellente expérience IDE de Mill facilite la compréhension du build et son modèle d’extensibilité évite les erreurs de configuration, si bien que dans Mill, la solution la plus simple est généralement la bonne
Aucun commentaire pour le moment.