FabeMaven c'est un peu l'ancêtre de tout ça, il va beaucoup moins loin en termes d'expressions de contraintes (il ne supporte pas semver) et ne propose pas de "lock-file", notamment.Je ne sais pas ce qui a poussé mes collègues à considérer Maven plutôt qu'un truc plus récent (j'ai en tête Gradle, je sais pas si c'est le "plus récent" ou pas ?). Par contre, on n'a pas directement ciblé "Maven" mais plutôt les "pom.xml" mais il me semble que c'est étroitement lié (Gradle utilise son propre mécanisme, même s'il peut gérer les pom.xml également).
FabeEn gros en Maven tu dépends d'une "release" ou d'un "snapshot". le second ayant la particularité d'être updatable, c'est à dire que pour le même numéro de version tu peux récupérer une version plus récente de la dépendance à chaque build. (genre 2.0.1-SNAPSHOT)C'est ce que mes collègues pensaient aussi car en pratique, on retrouve presque toujours un numéro de version dans le champ correspondant, mais en réalité, la syntaxe autorise des contraintes de dépendances (que l'on exprime sous forme d'intervalles, un peu comme avec NuGet d'ailleurs).
FabeBref, car je réalise que tu savais ptet déjà tout ça, du coup pour t'aider, je dirais bien de bricoler avec le plugin "dependency:tree" ou pourquoi pas du côté de ce genre de projet : github.com/ltearno/pom-e… mais je ne sais pas exactement ce que ça vaut.Dependency:tree utilise directement les données de Maven Central, et même si on peut lui indiquer un autre repository, ça veut dire qu'on va devoir générer un tel repository pour ne lister que les dépendances qui étaient disponibles "historiquement". Mais je vais jeter un oeil à pom-explorer, vu qu'on veut s'attaquer aux dépendances "internes" à la fondation Apache, ça a du sens d'utiliser quelque chose de multi-projects comme pom-explorer ! Merci !
Guybrushla syntaxe autorise des contraintes de dépendancesMouif, enfin comme il n'y a pas de lockfile, tu prends le risque de builder avec une autre version que celle avec laquelle tu as développé, et finalement la seule version qui compte vraiment est celle qui se trouve dans le classpath au moment du run. Spécifier une plage de version présente plus de risque que de bénéfices.
Guybrushj'ai en tête Gradle, je sais pas si c'est le "plus récent" ou pas ?C'est bien plus récent, moderne, et développé avec beaucoup plus de moyens que Maven.
Ce message a été modifié 1 fois.
Dernière modification : 10 juin 2018
à 21:25 par
Fabe.
FabeMouif, enfin comme il n'y a pas de lockfile, tu prends le risque de builder avec une autre version que celle avec laquelle tu as développé, et finalement la seule version qui compte vraiment est celle qui se trouve dans le classpath au moment du run. Spécifier une plage de version présente plus de risque que de bénéfices.Ok, c'est donc relativement similaire à la plupart des autres "écosystèmes" (npm, PyPI, Rubygems, ...). Dans notre cas, on utilise surtout les contraintes (et pas les lock files) car cela représentent la "latitude" que le mainteneur donne à ses dépendances (et c'est une source de problèmes, effectivement, donc on étudie notamment ça pour trouver des solutions autre que les lock files).
FabeC'est bien plus récent, moderne, et développé avec beaucoup plus de moyens que Maven.Ok, super ! Comme indiqué, ma connaissance du monde Java est vraiment faible, surtout que j'avais laissé Maven (pom.xml) de coté ces dernières années parce que ce type de manifest est vraiment ch... à analyser par rapport à d'autres écosystèmes (expansion des variables, héritage des pom.xml, etc. ça nécessite plus de travail que de simplement lire un package.json en npm Et vu qu'on travaille à grande échelle (ex: 8 millions de versions à traiter sur npm !), le moindre travail supplémentaire à réaliser représente potentiellement des jours de calcul supplémentaires !). C'est aussi la raison pour laquelle j'avais laissé tombé PyPI (il faut grosso-modo exécuter setup.py pour espérer récupérer des informations fiables, l'analyse statique du manifest n'est pas suffisante ).
En revanche pour un éditeur de lib Java, il "faut" être disponible sous Maven pour exister. Analyser les pom ça a du sens je pense.
Guybrushtrouver des solutions autre que les lock filesIl y a des hybrides, je connais des projets qui "gitignorent" le lock file pour avoir toujours les dépendances les plus récentes, et committent finalement le lock file au moment de la release afin de passer la chaîne de build de manière sécurisée uniquement au dernier moment.
Guybrushpremier niveau de dépendances, on n'a même pas regardé transitivement ce que ça pouvait donner !Sur les ecosysteme que je connais (PHP, Go, Rust), le lockfile ne s'applique qu'à l'application "racine", c'est à dire celle qui est en train de builder. Une dépendance intermédiaire ne peut donc pas "freezer" la version d'une dépendance transitive, sauf à le faire dans l'expression de sa contrainte. Les boulets du semver, ça peut arriver...
Ce message a été modifié 1 fois.
Dernière modification : 11 juin 2018
à 10:48 par
Fabe.
FabeIl y a des hybrides, je connais des projets qui "gitignorent" le lock file pour avoir toujours les dépendances les plus récentes, et committent finalement le lock file au moment de la release afin de passer la chaîne de build de manière sécurisée uniquement au dernier moment.Pour mes librairies (= composants réutilisables), je ne distribue pas les lockfiles, mais juste des contraintes relativement souples. J'ai un CI qui lance les tests chaque semaine, donc je suis relativement "aware" en cas de souci (et mes tests sont en général très couvrants
FabeSur les ecosysteme que je connais (PHP, Go, Rust), le lockfile ne s'applique qu'à l'application "racine", c'est à dire celle qui est en train de builder. Une dépendance intermédiaire ne peut donc pas "freezer" la version d'une dépendance transitive, sauf à le faire dans l'expression de sa contrainte. Les boulets du semver, ça peut arriver...Bon à savoir. Je pensais que ça fixait aussi les dépendances transitives (ce qui a du sens du point de vue réplicabilité). A ma connaissance, les outils dispo pour ça en Python fixent aussi les dépendances transitives, mais je ne sais pas pour les autres systèmes.
FabeEst-ce que tu t'es intéressé à Go dans ton étude ? Ces mecs sont vraiment des hippies de la gestion de dépendances, et s'appliquent à ne rien faire comme tout le monde.J'ai éliminé Go assez rapidement pour deux raisons :
Au début c'était "on a pas envie, ça a l'air chiant, donc ce sera github lol" suivi de plein d'itérations pour se rapprocher des autres ecosystèmes jusqu'à présenter une version stable de "dep", le package manager.
Et maintenant qu'ils ont un truc, ils projettent de tout péter pour gérer les breaking change dans l'import path (le projet github quoi) et appliquer ensuite un genre de "semver inversé" (on prend la plus petite version qui satisfait la contrainte du développeur).
Je sais pas si ça rentre dans ton champ, une telle obstination c'est à la limite de l'anthropologie
1996-2024 — Lexpage v4 — GPLv3 (sources)
page générée le 23 décembre 2024 à 15:08:10