C’est en discutant avec Hervé Boutemy que je me suis rendu compte que connaître les dépendances d’un artefact java répond à deux besoins : arriver à l’utiliser, ou pouvoir le construire.
Et je ne me rendais pas compte que c’étaient deux responsabilités complètement différentes.
C’est a priori l’objectif de Maven 5: séparer les responsabilités. Séparer les responsabilités des poms. Qu’il y ait deux poms. Le pom pour construire. Le pom pour utiliser. (Je ne parle que de la responsabilité de décrire les dépendances.)
Niveau 1 : j’utilise un artefact.
Niveau 2 : je publie mon artefact.
Niveau 3: je modifie (reconstruis) un artefact publié.
Niveau niveau : je modifie (reconstruis) maven pour construire mon artefact.
Bootstrap.
Le projet Maven ne maintient plus le script ant permettant de constuire l’outil maven. Pour construire maven, vous avez besoin de maven. (Mais Debian en maintiendrait un : ils se sentiraient donc responsable de pouvoir recréer un système à partir de rien ?).
Et que c’était pour ça que je ne me retrouvais pas dans la réponse que donnait mon collègue devops à la question du béotien : « c’est quoi Maven ? ».
Pour moi, Maven me permet d’éviter de gérer le classpath.
Pour lui, Maven permet d’alimenter la pipeline CI/CD.
C’est le même objectif : arriver à construire un artefact. Mais dans notre histoire, on n’a pas les mêmes souffrances. Lui, c’est d’avoir un endroit qui centralise les différentes étapes de construction d’un artefact, de manière que ce soient les mêmes dans tous les environnements – c’est un vrai dévops. Moi, de ne plus gérer ce cauchemard de classpath, surtout en dev, et notamment dans les phases d’exploration – comment ça sera en prod n’est pas vraiment mon problème. Je me rends compte qu’avoir passé quelques années dans des PME, à livrer sur des répertoires réseau des jar construits en dev m’a empêché de prendre véritablement le virage devops industriel. Et à ma décharge, j’étais dévops, c’est bien ce qui était en dev qui partait en prod :).