- Ein schnelles und skalierbares mehrsprachiges Build-Tool mit Unterstützung für Java, Scala und Kotlin
- JVM-Build-Tools gelten oft als langsam und unübersichtlich, aber Mill ist darauf ausgelegt, Performance und Bedienbarkeit der JVM maximal zu nutzen
- Kann dieselbe Java-Codebasis 5–10-mal schneller als Maven und 2–4-mal schneller als Gradle bauen
- Hält Builds mit einer typisierten Konfigurationssprache und einem unveränderlichen Task-Graphen sauber und leicht verständlich
- Skaliert gut von kleinen Einzelmodul-Projekten bis hin zu großen Monorepos mit Hunderten von Modulen
Vorteile von Mill
- Performance: Der Build-Graph von Mill cached und parallelisiert Build-Tasks automatisch, damit Workflows schnell und reaktionsfähig bleiben. Gleichzeitig bietet Mill Werkzeuge, um Engpässe im Build zu identifizieren und zu beheben, und fügt der für den Projekt-Build nötigen Logik nur minimalen Overhead hinzu
- Wartbarkeit: Statt auf YAML und Bash setzt Mill auf kompakten, typgeprüften Code für Konfiguration und benutzerdefinierte Logik sowie auf unveränderliche Modulbäume und Task-Graphen. So lassen sich Konfigurationsprobleme früh erkennen, und IDEs (IntelliJ oder VSCode) können Mill-Builds besser verstehen als andere Build-Systeme
- Flexibilität: Die Tasks und Module von Mill erlauben alles von einfachen zusätzlichen Build-Schritten bis hin zu kompletten Sprach-Toolchains. Man kann jede JVM-Bibliothek in den Build einbinden, das umfangreiche Ökosystem an Drittanbieter-Mill-Plugins nutzen oder eigene Plugins schreiben und auf Maven Central veröffentlichen, damit andere sie verwenden können
Mill im Vergleich zu anderen Build-Tools
- Mill übernimmt Ideen aus anderen Tools wie Maven, Gradle und Bazel, versucht aber, die Stärken jedes Werkzeugs zu nutzen und ihre Schwächen zu verbessern
- Mill vs Maven
- Mill folgt Mavens Innovation, gute Standardwerte bereitzustellen
- Das integrierte
JavaModule von Mill folgt dem Maven-Stil „Konvention vor Konfiguration“, sodass kleine Mill-Projekte nur minimalen Aufwand zum Start benötigen und größere Mill-Projekte auf diesen Standardwerten mit einer konsistenten Struktur aufbauen können
- Mill cached und parallelisiert Builds automatisch und erzielt dadurch eine Beschleunigung um das 3- bis 10-Fache
- Das gilt nicht nur für die mitgelieferten eingebauten Tasks, sondern auch für benutzerdefinierte Tasks oder Module. Das maximiert die Agilität von Build-Workflows auf der Kommandozeile und hilft, die Produktivität hochzuhalten, besonders bei größeren Codebasen, bei denen Builds tendenziell langsamer werden. Wo ein Maven-Workflow mit „clean install“ mehr als eine Minute dauern kann, kann Mill dafür nur wenige Sekunden benötigen
- Mill lässt sich deutlich einfacher anpassen als Maven
- Projekte wachsen meist über das bloße Kompilieren einer einzelnen Sprache hinaus. Es braucht benutzerdefinierte Codegenerierung, Linting-Workflows, Tool-Integrationen, Ausgabe-Artefakte oder Unterstützung für zusätzliche Sprachen. Mills Erweiterbarkeit und IDE-Erfahrung machen es einfach und sicher, all das direkt über typgeprüften Code und sandboxed Tasks umzusetzen
- Mill vs Gradle
- Mill folgt der Prägnanz und Erweiterbarkeit von Gradle
- Statt seitenlangem XML hat jede Zeile in einem Mill-Build Bedeutung. Das Hinzufügen einer Abhängigkeit ist in Mill zum Beispiel wie bei Gradle nur eine Zeile, im Gegensatz zu den fünf Zeilen einer
<dependency>-Deklaration, wie man sie aus Maven kennt. Ebenfalls wie bei Gradle können Endanwender ihre Builds leicht an genaue Anforderungen anpassen, ohne erst den Weg über das Schreiben eines Plugins gehen zu müssen
- Mill kann 2- bis 3-mal schneller sein als Gradle
- Mill und Gradle cachen und parallelisieren Builds beide automatisch, aber Mill erreicht das mit deutlich geringerem festem Overhead. Das bedeutet weniger Wartezeit auf das Build-Tool und mehr Zeit für die Dinge, die für das Projekt wirklich wichtig sind
- Mill setzt Best Practices standardmäßig um
- Jeder Teil eines Mill-Builds ist standardmäßig gecached und inkrementell. Jeder Mill-Task schreibt seine Ausgaben an einen Standardort. Alle Abhängigkeiten zwischen Tasks werden automatisch ohne manuelle Annotationen erfasst. Während Gradle erheblichen Aufwand und Fachwissen erfordert, um Builds zu verstehen und korrekt einzurichten, macht die starke IDE-Erfahrung von Mill Builds leichter verständlich, und das Erweiterungsmodell hilft dabei, Fehler in der Build-Konfiguration zu vermeiden – sodass in Mill meist der einfachste Weg auch der richtige ist
Noch keine Kommentare.