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.
Je résume ici : vous travaillez pour un grand groupe (aller au hasard une grosse banque) et vous devez utiliser yarn (un remake de npm mieux foutou). Jusque là aucun soucis sauf que le proxy de la grosse banque fait du man-in-the-middle aux yeux et à la vue de tout le monde. Donc yarn quand il veut choper des trucs pas forcément utiles en SSL (genre phantomjs, le bouzin qui fait juste tourner NOS TESTS UNITAIRES) bah il veut pas le p'tit chaton parce qu'il se rend bien compte que les mecs du proxy : ils font du man-in-the-middle comme des gros porcs.
Bref, voici comme détruire toute forme de sécurité dans yarn mais qui vous permettra (a minima momentanément) de récupérer des tools genre phantomjs :
yarn config set "strict-ssl" false
et pour restaurer la sécurité ce sera évidemment :
yarn config set "strict-ssl" true
Supprimer la journalisation de ext4.
Les commandes à exécuter sur des partitions non montées (donc depuis une clef usb bootable par exemple) :
sudo tune2fs -O^has_journal /dev/sda3
sudo e2fsck -f -v -C0 /dev/sda3
Attention, désactiver la journalisation augmentera énormément les performances ainsi que la durée de vie de votre disque SSD. Mais en cas de coupure de courant, vous risquez une totale des données qui étaient en cours d'écriture.
Donc oui pour de la bureautique mais jamais ô grand jamais pour un serveur.
UNE VARIANTE ============================ CELA SIGNIFIE PAS LES DEUX EN MÊME TEMPS !
Une variante consiste à utiliser un autre mode de journalisation (par défaut il y en a trois). Cela se passe dans la fstab :
/dev/sda2 / ext4 noatime,defaults,data=writeback 0 1
Il faut ajouter l'option data=writeback et redémarrer.