Antichesse (o ^ω^ o)
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.
Un outil permettant de savoir si votre code utilise des API obsolètes ou dépréciées en Java.
Pour citer l'article.
mvn versions:display-dependency-updates
Scans a project’s dependencies and produces a report of those dependencies which have newer versions available.mvn versions:display-plugin-updates
Scans a project’s plugins and produces a report of those plugins which have newer versions available, taking care of Maven version prerequisites.mvn versions:display-property-updates
Scans a project and produces a report of those properties which are used to control artifact versions and which properties have newer versions available.
Voilà la solution :
<plugin>
<groupId>org.graalvm.nativeimage</groupId>
<artifactId>native-image-maven-plugin</artifactId>
<version>19.3.0</version>
<executions>
<execution>
<goals><goal>native-image</goal></goals>
<phase>package</phase>
</execution>
</executions>
<configuration>
<skip>false</skip>
<buildArgs> --no-fallback </buildArgs>
</configuration>
</plugin> Imaginez, vous êtes en prestation pour une grosse boite et la cellule d'architecture de votre client active tout un tas de plugins Maven sans comprendre comment fonctionnent ces plugins et ni Maven d'une manière générale.
Vous souhaitez donc bloquer l'héritage de la configuration de ces plugins pour ne laisser que les vôtres. Évidemment vous êtes quand même obligé d'hériter du pom parent provenant de la cellule d'architecture pour récupérer quelques properties bien utiles.
Solution :
1) Vous créez un pom abstrait à la racine de votre projet.
2) Dans ce pom vous ajoutez plugin par plugin (ici avec ANT) la désactivation <inherited>false</inherited>:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.2</version>
<inherited>false</inherited>
...
</plugin>
</plugins>
</build>
...
</project>3) Vous créez un second pom abstrait, enfant du premier et duquel héritera tous vos modules.
Et voilà, les modules n'auront plus connaissance des plugins du super-parent.
L'idée n'est pas mal : vous ajoutez des annotations dans votre code Java et un processeur d'annotations piloté par un plugin Maven va générer pour vous la configuration Kubernetes de votre application. Etant donné que je n'aime pas trop m'embêter avec Kubernetes (je n'arrive plus à apprendre toutes les technos de la terre, surtout les technos ops, elles sont en train de me tuer), j'apprécie d'autant plus cette initiative.
Via Riduidel.
La page de configuration du plugin que je ne retrouve jamais.
Si vous utilisiez le plugin gulp-webpack il vaut mieux passer à webpack-stream qui est son remplaçant. Pour l'instant, j'utilise Webpack à travers Gulp à la main, mais si webpack-stream est efficace et réduit la quantité de code des mes tâches Gulp, alors je migrerai.
Je vais faire ma reloue, mais je vous assure qu'écrire du code pour builder du code est une hérésie. Dommage qu'il n'y ait pas de plugin Aurelia pour Brunch.
Je suis à la recherche d'un meilleur éditeur de sources pour Kotlin.
Bordel, VS Code de Microchiotte est en passe de devenir mon premier choix !
Il ne me reste plus qu'à migrer sur Gradle et je me serai convertie.
Si l'on m'avait dit cela il y a quelques années...
La doc officielle de Sonatype à propos de la création de plugins.
Créer un plugin pour SonarQube
Aparté
Il y a trois choses qui manquent cruellement à NetBeans à mon sens par rapport à IntelliJ :
1) Une meilleure intégration de Kotlin.
Je précise ma pensée :
- La coloration syntaxique custom en Kotlin qui saute après chaque reboot (c'est quand même la loose).
- Le fait que l'IDE ne parvienne pas à importer les classes d'un module Maven Kotlin depuis un module Maven Java (seconde loose).
2) Pas de plugin Infinitest (troisième loose)
3) La smart completion d'IntelliJ
Vu que j'ai besoin de Kotlin en ce moment et d'infinitest, bah IntelliJ du coup !
Faudra que je parle des pours des contres de chacun de ces deux IDE, parce que NetBeans est quand même beaucoup plus rapide qu'IntelliJ, l'intégration Maven est carrément meilleure (mais je veux dire vraiment) et les commandes de refactoring automatiques sont plus efficaces, il est mieux intégré aux plateformes d'intégration continue, sa gestion de Docker et d'Ansible, etc. Bref vous m'avez comprise.
Notifier votre plateforme d'intégration continue des changements effectués dans votre application.
Un plugin Maven pour exécuter les tests unitaires à chaque changement et recompiler les classes aussi. Cela permet à Maven de rattraper un peu Gradle sur ce sujet et de proposer ce qu'il est possible de faire en JS.
Tout est dans le titre. J'ajouterai qu'il est préconisé par le responsable de NetBeans himself
Comment développer son propre plugin Sonar (Chlouchloutte, je pense à mon projet District)