Antichesse (o ^ω^ o)
Je me note :
- Angular 12.x => NodeJS 14
- Angular 13.x => NodeJS 16
- Angular 14.x => NodeJS 16
Edit : Pitest marche avec TestNG finalement ! Il faut rajouter ceci au plugin (info que j'ai trouvée dans la conf Gradle d'une application Android mais pas dans la doc officielle) :
<plugin>
<groupId>org.pitest</groupId>
<artifactId>pitest-maven</artifactId>
<version>${version.pitest}</version>
<configuration>
<testPlugin>testng</testPlugin>
</configuration>
</plugin>Merci à @Animal et @Kysofer qui m'ont accompagnée très tard cette nuit sur Framatalk.org ! #BestBuddiesEver
Depuis hier je me casse les dents sur Pitest dont j'ai parlé à deux reprises ici et ici. Pour faire simple un client m'a demandé de le mettre en œuvre sur nos projets mais impossible de le faire marcher :'(
Comme ce soir tout le monde est couché depuis 1h30 et que j'ai l'esprit frais, je me suis dit que j'allais réessayer mais en changeant ma démarche. Cette fois-ci je prendrai un projet sur internet et qui fonctionne puis j'en modifierai sa configuration pour la faire converger vers celle de mon projet jusqu'à ce qu'elle pète.
Conclusion : Pitest ne fonctionne pas avec TestNG (et j'ai essayé toutes les versions majeures de la 6.1.1 conseillée par le site de Pitest jusqu'à la 7.3.0, dernière version en date).
Bref, cela faisait quelques temps que le couple TestNG + AssertJ me posait problème dans le sens où TestNG était moins bien pris en charge par certains framework et je vais a priori devoir faire un retour arrière pour le couple JUnit Jupiter + AssertJ (oui je conserve AssertJ, plus jamais les assertions de JUnit, viva la fluent-expressive API d'AssertJ).
Une des nombreuses raisons pour lesquelles je préfère éviter l'écosystème Spring Boot le plus possible. Tout étant basé sur le scanne du classpath, rien n'est vérifiable au build et tous les imports sont validés/calculés au runtime.
Bref, avant Spring et Spring Boot nous avions un environnement Java où tout était vérifié à la compilation, fortement typé statiquement et à présent nous avons une sorte de clone verbeux de JavaScript avec des temps de build (ce que JavaScript n'a pas puisque interprété) et des temps de démarrage hyper-longs (ce que JavaScript n'a pas puisque interprété).
Bref si c'était pour transformer Java en JavaScript merci mais non merci.
Sinon Kotlin + Jooby + Ktorm sur JVM ça remplace totalement Java + Spring Boot + Hibernate, c'est plus simple (pas de conflits internes de versions, pas de mécaniques implicites obscurs à connaître), ça prend littéralement 10 fois moins d'espace disque pour faire la même chose et c'est plus rapide (démarrages instantanés, tient plus de 100 fois mieux la charge d'après techempower).
Edit : le lien à jour : https://spring.io/projects/spring-cloud
Vous le savez peut-être, je ne suis pas fanna de Spring mais comme tous mes clients l'utilise, il faut bien que je me maintienne à jour.
Ici, le tableau de compatibilité des versions entre Spring Cloud et Spring Boot.
En résumé : Spring Cloud Hoxton s'attend à ce que vous lui tiriez Spring Boot 2.2.x.
Quel scanner choisir pour qu'il marche impec sous Linux
Coudifié
La table des compatibilité de JavaScript.
Vu que c'est méchamment le bordel en JavaScript voici une table de compatibilité des fonctionnalités plus ou moins répandues en fonctionne des environnements d'exécution.