Antichesse (o ^ω^ o)
Je pense que Crédic Champeau et les personnes argumentant en faveur du DSL Gradle dans les commentaires "just miss the point".
1) Le DSL ne permet pas d'hériter ou d'inclure un processus de build unique, public, documenté et standard, ce qui est indispensable en industrie. Certains répondraient qu'il est possible de le coder directement dans un plugin ce à quoi je réponds :
- Écrire du code qui va compiler du code, the what ?
- Mais admettons, je code le-dit plugin, si alors j'ai besoin de me sortir partiellement du processus standard que dois-je faire ? Forker le plugin ? Donc je rajoute du code à du code qui va compiler le code ? Encore une fois the what ?
2) Même en écrivant en DSL Gradle de manière déclarative, l'ordre des déclarations est important, ce qui de facto rend le code impératif puisqu'il nécessite de penser en termes d'ordonnancement de l'instantiation des élements qui constituent le DSL, ce qui n'est pas déclaratif.
3) Les DSL ne m'intéressent pas. Ta techno => tes problèmes. Je dois déjà faire du Kotlin, du Java, du TypeScript, du Spring, du Spring Boot, du Spring Cloud, du JPA, du Lombok, du Mapstruct, du Jackson, du Zuul, de l'Open API, de l'Ansible, du Docker, du Kubernetes, du SCSS et CSS, du Bootstrap, de l'Angular, du Karma, du JUnit Jupiter, du Mockito, du WireMock, du Rest Assured, du Protractor, du npm, du Maven, de l'Angular-cli, du SSL, du Linux (ssh + systemctl + GNU tools), du bash et du dash, du GraalVM, du Jasmine, de l'AOP (AspectJ), du Spring Data (JPQL), du Liquibase, du SQL, du PL/SQL, du REST, du SOAP, de l'Apache CXF, du HazelCast, du SonarQube, de l'OAuth2, et du clean code + clean architecture + Domain Driven Design + architecture hexagonale + Design Patterns et tout ça c'est uniquement sur un seul projet (il y en a une trentaine) et là on me dit qu'il faut que j'apprenne deux langages de plus (Groovy + DSL Gradle) juste pour compiler du code ? Comment leur dire à ces messieurs ? Nous ne vivons pas dans le même monde.
Bref, Maven Daemon pour speed up les builds + les pom de Maven écrits en Yaml et c'est bon.
@Sebsauvage mais oui cette mode des logiciels libres qui nous trahissent !
Récemment j'ai fait la promotion de Maven Daemon qui est un fork de l'outil de build Apache Maven dédié aux langages Java (et d'une manière générale à tous les langages qui tournent sur une JRE).
Et bien c'est en l'installant chez un client que je me suis rendu compte que l'outil envoyait une requête vers AWS à chaque commande (o_Ô) !!
Et même en essayant de grepper l'url dans les sources, impossible d'identifier où l'appel était codé ! Bref, je suis revenue à Apache Maven à défaut d'avoir un outil de build clean (le temps de produire un patch) :'(
J'ai bidouillé mvnd cette semaine et je l'ai testé sur un projet de 29 modules écrits en Kotlin (il s'agit du projet commons de Lenny, Gejel et Kysofer pour ceux qui savent).
Résultats :
- Le build incrémental sans clean est passé de 4 min 20 à 1 min 53.
- Le build incrémental avec clean est passé de 4 min 43 à 2 min 05.
- Le build prod (optimisant le code + vérifs) sans clean est passé de 4 min 56 à 2 min 21.
- Le build prod (optimisant le code + vérifs) avec clean est passé de 4 min 58 à 2 min 22.
- L'analyse statique du code (SCA + SAST + LINTER) est passée de 5 min 11 à 2 min 17.
Conclusion simple, Maven Daemon ça marche !
Actuellement l'outil n'embarque pas encore de LSP (Language Server Page) incluant recompilation ciblée + exécution partielle des TU via graphe des dépendances, mais quand ce sera le cas, les temps de build devraient être divisés par 2 ou 3 ce qui correspondrait aux temps de build de Gradle sans avoir besoin d'écrire du code (via DSL Groovy ou Kotlin) pour compiler du code, pratique qui je l'affirme est une hérésie que les devops d'antant avaient presque réussi à tuer.