Un drôle de plugin Maven qui permet de déclarer un paquet de dépendances dans le dependency management, mais de les voir apparaître comme dépendances réelles uniquement lorsqu'elles sont utilisées en tant que module Java. Enfin une bonne raison d'utiliser les modules ? Peut-être ... Mais je ne vois pas trop l'intérêt de déclarer des dépendances qu'on n'utilise pas (sauf bien sûr quand on …

Un détecteur de dépendances maven inutile. La plupart du temps, _a ne sert à rien. Mais sur un projet qui a dix ans, ça peut être utile

Un très sympathique plugin maven générant un graphe de dépendance visuel (et filtrable) d'un projet maven aux formats GraphML, dot, ou PlantUML

Google fournit un service qui permet d'avoir des informations basiques sur les dépendances de langages très courants (Java, PHO, Python, Javascript, Go, Rust, ... ET C'EST TOUT). Pour ces langages, c'est un moyen pratique d'aggréger l'information sous une forme standardisée. Pour les autres langages, ça reste la guerre des tranchées.
Mais méfiance : c'est fourni par Google, donc on ne sait pas quand ça s'arrêtera de marcher (oui, je FUDe)

Un nombre unique, ça fait toujours plaisir aux managers. Surtout quand on peut l'intégrer dans le build (maven ou autres)

Un outil intéressant qui expose les packages NPM comme des artefacts maven. Ca peut être intéressant pour ceux qui veulent se passer de npm ...

Un article sacrément intéressant, auquel je vois néanmoins un biais (pour lequel je n'ai pas vu la solution dans l'article) : je ne sais pas si depclean supprime les dépendances simplement parce qu'elles sont trop grosses, ou parce qu'elles sont trop grosses et inutiles.

Rust c'est très cool, mais parfois, on se retrouve avec un peu trop de dépendances (parce qu'il ne semble pas y avoir de convergence des dépendances). Pour éviter ça,cargo bloat donne les dépendances qui prennent de la place.

Je vois très bien l'usage que je pourrais faire d'un tel système qui permet de visualiser les dépendances de tickets Gitub

Très chouette article donnant le postulat de base de l'architecture hexagonale, et de ces autres concepts d'artisanats logiciel

J'ignorais ça (et honnêtement, ça m'aurait parfois servi)

Trouvé via Julien Kirch, une idée intéressante (et qui plaira au moins à un ancien collègue)

Ce truc-là, c'est vraiment de la merde apocalyptique. Je pourrais détailler, mais ca m'énerverait encore plus.

Ca me rappelle une discussion avec Hubert S., même si je ne mets pas les mêmes indicateurs, ni le même poids à ces indicateurs.

C'est très chouette, et ça pourrait presque se rapprocher de ce qu'on peut faire en OSGi depuis ... 10 ans ? Mais comme c'est le standard de modularité d'Oracle, il va bien falloir s'adapter.

C'est une très bonne idée d'Hubert d'essayer de recontextualiser la présence de dépendances ...

J'avais déja vu ce conseil, et le voir développé me fait assez plaisir, parce que c'est une sacrément bonne idée.

Je savais que je pouvais avoir plusieurs versions d'une dépendance mais je ne savais pas comment ça marche ... Maintenant que je sais, je trouve ça dinguement génial (et tellement mieux que Java/Maven)

C'est bien cet outil pour générer le fichier requirements.txt, qui est indispensable mais peu pratique

Un ancien collègue ne pourrait qu'être d'accord avec cette vision de l'enfer des dépendances Javascript (même moi, j'approuve)