Problème

Vous développez un plugin Maven qui doit valider des trucs sur vos projets. Dans certains cas le plugin doit planter le build, dans d'autres cas, le plugin ne fait pas planter le build.

Ce plugin sert au premier cas, car la présence d'erreur arrête le build, dans ce cas, une erreur souhaitée lors d'un test ne fait plus planter le build :

<plugin>
    <groupId>com.soebes.itf.jupiter.extension</groupId>
    <artifactId>itf-maven-plugin</artifactId>
    <version>0.13.1</version>
</plugin>

Merci à @Philou pour le lien (ça faisait longtemps) !

Un plugin Maven qui ne rebuild qu'en cas de changement.

Ça doit faire 4-5 ans que je me remets régulièrement à Gradle dans l'espoir de trouver une solution à un problème pourtant trivial : comment, avec Gradle, mutualiser un processus de build qui doit s'appliquer sur plusieurs projets qui n'ont rien à voir ?

Gradle confond la notion de projets et de modules, donc je dois clarifier ces deux définitions pour la suite :

• Un module, c'est ce qui va produire un jar au sein de votre projet Git et votre projet est composé de modules.
• Donc yn projet, c'est un répo Git et qui en général va produire une application et les modules la composent.

Dans toutes les docs de Gradle, un projet est un module, donc pas besoin d'héritage puisque le build.gradle à la racine va injecter sa conf dans les build.gradle des modules positionnés dans les sous-répertoires.

Sauf que ce genre de bidouilles, ça marche bien dans une startup ne concevant qu'un seul produit, mais imaginez que vous deviez proposer un socle de build gérant Java, Kotlin, Groovy et Scala et qui soit utilisé par 2000 personnes, sur plus de 100 applications et 200 libs, comment faites-vous avec Gradle ?

Permettez-moi de détailler, le processus de build standard inclut :

• La compilation en mode dev (sans optim) et en mode prod (avec optim).
• Les analyses de sécurité.
• Les analyses de code.
• La signature des jars.
• La production des jars des docs et des sources.
• Les analyses des dépendances.
• Etc.

Tout ce processus qui est agnostique du code lui-même DOIT être factorisé pour devenir un standard de l'entreprise et se pose en tant que quality-gate/build-breaker en cas de manquement.

Avec Maven facile, il suffit que le pom parent de votre projet hérite du pom sachant faire tout ça, mais comment faire avec Gradle ? Ce build.gradle "commun" ne peut pas être hérité car Gradle ne permet pas l'héritage et il ne peut pas lancer lui-même le build des 300 répos dont les produits ont des cycles de vie totalement indépendants.

C'est une vraie question car j'aimerai vraiment abandonner Maven (puisqu'il est beaucoup trop lent) au profit de Gradle, mais sans la capacité de mutualiser le processus de build entre deux projets indépendants, cela fait de Gradle un outil pour "amateurs", or sa percée sur le marché me pousse à croire qu'il doit bien exister une astuce mais que je n'ai encore jamais vue. Bref si quelqu'un a l'info...

Comment créer un build reproductible avec Gradle :

tasks.withType(AbstractArchiveTask) {
    preserveFileTimestamps = false
    reproducibleFileOrder = true
}

Rappel : un build reproductible consiste en un processus qui soit capable de fournir le même binaire (à l’octet près) entre deux commandes de build jouées à deux dates différentes. Comme les archives JAR embarques un timestamp qui chronodate le jour et l'heure build, par défaut ça n'est pas possible.

Merci @Bronco. C'est marrant parce que j'en parlais avec @Lenny ce midi (je suis tombée sur Fontello par hasard ce matin). En fait, j'aimerai une opération qui soit 100 % utilisable dans une PIC (ie. Plateforme d'Intégration Continue pour ceux qui ne connaîtraient pas l'acronyme).

L'idée serait de pouvoir récupérer l'intégralité des fonts en local via une commande Yarn/NPM puis de produire le bundle avec juste ce qu'il faut, au moment du build, en ne déclarant que celles utilisées (dans une tâche Gulp par exemple).

Ce qui me gène dans Fontello, c'est qu'il faut cliquer, et donc qu'un humain doive le faire au moins une fois, puis à chaque mise à jour du set d'icônes ; augmenter ainsi la probabilité d'un oubli d'une icône précieuse au fil du temps...

La meilleure option reste de déclarer l'ensemble des icônes souhaitées dans une conf et de laisser le build produire l'archive qui va bien. Si je trouve une solution, je la posterai.

Comment configurer et améliorer le build d'une application Aurelia via le plugin aurelia-webpack-plugin ?

Pour tout vous dire et sans trop forcer hier soir, en reparamétrant le build d'un des projets de @Lenny et @Kysofer, la taille du bundle JS s'est réduite de 12,8% et au vu de mes tests, nous devrions êtres en mesure de récupérer 15% à 20% de plus.

Cela fait de nos SPA que leurs pages d'accueil ne dépassent jamais les 685 Ko tout compris (ie. HTML + JS + CSS + IMG + FONTS) et moins de 180 Ko en utilisant une compression Gzip sur les fichiers statiques.

En ajoutant à cela un cycle de release non continu pour ne pas perdre les bénéfices de la mise en cache côté navigateurs, nous nous retrouvons avec une page de garde ne requérant plus que 3,6 Ko à télécharger lors de la seconde connexion et des suivantes.

Essayez d'en faire autant avec Angular et Bootstrap ! Je maintiens que le combo TypeScript + SCSS + Aurelia + Bulma + Karla Fonts + Font Awesome + TinyPNG est le plus efficace. J'ai vraiment hâte de passer à Aurelia 2 en 2020 !!! ٩(◕‿◕｡)۶

Il est très difficile de créer des builds reproductibles en Java via Maven / Gradle & Co. Cette très courte présentation explique bien pourquoi.

Heureusement, il existe un plugin maven permettant de virer les timestamps et les méta-data pour rendre le build reproductible à l'octet près.

Encore une fois, merci à @Philou pour l'info.

Trouver quels jars sont en conflits dans votre build Maven en une ligne : mvn dependency:tree -Dverbose

Builder des modules en parallèle sous Maven, je me le note pour reminder (car je l'oublie tout le temps) :

mvn -T 4 clean install        # Builds with 4 threads
mvn -T 1C clean install      # 1 thread per cpu core
mvn -T 1.5C clean install   # 1.5 thread per cpu core

Edit 2 : bon aurelia-bundler ne peut fonctionner qu'avec JSPM qui dépend de SystemJS. Or la liste des dépendances de JSPM se trouvent dans un fichier s'appelant config.js... M'voilà. J'abandonne et je reste sur le build Aurelia/Webpack.

Ça me saoule car j'espérais vraiment mettre en place un build plus simple, voire de créer un plugin Aurelia pour Brunch mais c'est trop long, trop de choses à maîtriser, trop de trucs qui changes tout le temps, trop de hypsters s'imaginant fournir la nouvelle techno de demain et qui préfèrent ne pas apporter leur soutien à un projet existant (car ils recherchent la gloire et non l'émancipation du système tout marchand). Le problème avec JS, ce sont les gens qui codent en JS pour JS.

Edit : après avoir testé, le tuto ne fonctionne pas (comme quasiment tous les tutos avec Aurelia). J'ai l'impression que le aurelia-bundler ne fonctionne qu'avec JSPM. Mon problème avec ça ? C'est que j'ai déjà un gestionnaire de paquet intégré à mon outil de build et que ce gestionnaire s'appelle NPM ! D'autant que JSPM est un utilitaire qui n'a jamais décollé et ça n'est pas près d'arriver !

Plus j'utilise Aurelia et plus que je trouve ce framework est merdicimale juste à cause du build ! L'utilitaire au aka aurelia-cli passe son temps à réinventer la roue et à tout faire pour surcharger la conf standard d'outils connus, documentés et maîtrisés comme le sont Gulp, NPM. Pourquoi faut-il que les développeurs d'Aurelia utilisent toujours la dernière techno-hype merdique qui n'a pas encore eu le temps de percer, c'est chiant à la fin ! Si encore ils s'étaient appuyés sur Brunch pour réutiliser quelque chose d'existant et de simple plutôt que de tout refaire à leur sauce en mode hypster-à-la-noix.

Le plus terrible c'est que la communauté derrière le framework Aurelia revendique qu'il est l'un des frameworks les plus respectueux des standards... Mais dès qu'il s'agit du build, ils sont encore pire qu'Angular c'est vous dire à quel point le niveau de médiocrité est ineffable.

Bref, je continue mes investigations en espérant comprendre par moi-même comment fonctionne le aurelia-bundler et surtout à quoi sert ce foutu fichier config.js (je pressens qu'il a un lien avec JSPM, auquel cas je sens que je vais hurler car je fais tout mon possible pour avoir un build 100% Gulp + NPM et rien d'autre).

Comment utiliser l'API du aurelia-bundler directement dans Gulp et s'éviter Webpack ?

Je me permets d'ajouter un truc qui me frustre avec Aurelia : c'est un framework à la Spring ou à la JEE qui se prétend modulaire mais où chaque élément de la couche supérieure va tirer un élément de la couche inférieure.

Essayez de remplacer la DI de Spring, Aurelia ou Angular par une autre pour voir. C'est juste impossible, car le couplage entre les modules y est total ! #DesignDeNoob

Mais en vérité cette "erreur de design" arrange bien son fabriquant puisqu'il rend le développeur captif du framework et lui évite d'aller prendre une lib chez la concurrence. #PorteOuverteVersLesAutres

Ma décision pour 2019, trouver des micro-frameworks, indépendants, interchangeables et légers, pour le front, à l'image de ce que sont Sparkjava (web serveur REST), ActiveJDBC (ORM), Feather-java (DI) ou encore Jsoniter (conversion entity-json) pour le back sur JVM.