Une suppression est aussi un changement. Dans un fichier de build, elle peut déplacer un classpath sans que personne ne le voie. Cette pull request retirait trois lignes du build.gradle de Kafka, et presque tout son contenu servait à prouver que rien d'autre ne bougeait.

Les doublons

Gradle résout une configuration comme un ensemble, la seconde déclaration de chaque paire est donc sans effet. Ça, c'est la théorie. Je voulais la mesure.

La preuve

./gradlew :connect:runtime:dependencies --configuration testCompileClasspath
./gradlew :connect:runtime:dependencies --configuration testRuntimeClasspath
./gradlew :core:dependencies --configuration testCompileClasspath
./gradlew :core:dependencies --configuration testRuntimeClasspath

Les quatre rapports sont identiques à l'octet avant et après, à 241, 418, 498 et 760 lignes, et les ensembles de modules résolus correspondent exactement, à 73, 104, 125 et 171 modules.

Le détail qui comptait

Dans chaque paire, j'ai retiré la déclaration la plus tardive, pas la première. Supprimer la ligne 1221 de core au lieu de la 1230 fait passer apachedsCoreApi derrière libs.apacheda dans l'ordre de déclaration, et le rapport liste alors api-all avant apacheds-core-api. Même ensemble, ordre différent. Retirer la ligne tardive garde chaque position, donc l'ordre du classpath, exactement tel quel.

Les deux jeux de sources de test compilent, les tâches de vérification passent avec checkstyle, spotbugs et spotless, rat passe à la racine, et en contrôle ponctuel WorkerTest a exécuté ses 140 tests sans échec.

Ce que j'en retiens

Dans un projet de la taille de Kafka, un nettoyage n'est bienvenu que s'il ne coûte rien au relecteur en confiance. Le diff tenait en trois lignes rouges. La pull request était la preuve qu'on pouvait les supprimer sans risque.

Ayoub Hammoudi, Ingénieur logiciel, full-stack et plateformes IA. github.com/Ayoubhm07