Journal Artifact Listener - Service de notification pour Maven Central - Java inside

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
21
29
mai
2013

Bonjour,

Bon, cela faisait un petit moment que nous bossions là-dessus et il est temps de lâcher le bébé dans la nature…

Motivations

Pour à peu près tous les développeurs Java, Maven Central est le dépôt de référence qui permet de récupérer une grande partie des composants Java (aussi appelés artifacts dans le vocabulaire Maven) - qu'on utilise Maven ou non d'ailleurs.

Suivre les mises à jour de ces composants quand on en utilise un certain nombre (dans notre socle, on en a environ 80) devient vite une gageure : suivre les diverses listes -announce, aller sur les sites web, suivre des projets sur Twitter, essayer d'utiliser l'inutilisable flux RSS de mvnrepository.com, lancer périodiquement une commande Maven, des possibilités qui prennent vite beaucoup de temps avec une efficacité toute relative, d'autant que les artifacts arrivent souvent sur Maven Central avec un petit décalage temporel par rapport à l'annonce de la sortie.

Du coup, on a décidé de créer un outil qui nous envoie les notifications des artifacts qui nous intéressent et vu que ça ne coûtait pas beaucoup plus cher de le rendre multi-utilisateurs, on en a profité pour le faire.

Le principe est simple :
- on s'inscrit
- on cherche les artifacts qui nous intéressent : le plus simple étant encore de faire analyser son pom.xml directement par l'application
- on les ajoute dans les artifacts qu'on suit
- on reçoit les notifications par mail quand une nouvelle release d'un artifact qui nous intéresse arrive sur Maven Central

L'outil se base lourdement sur les API offertes par Sonatype sur search.maven.org.

Bon, l'introduction est longue histoire que le lien ne soit pas tout de suite cliquable dans la liste des journaux, ça permettra peut-être à la petite VM qui l'héberge de survivre…

Evolutions prévues

Dans les hypothétiques tuyaux des évolutions futures, on a en tête :
- regrouper les artifacts sous des projets
- donner la main aux gens pour qu'ils puissent coller des notes de version, liens… sur une version
- d'autres trucs un peu dans le même genre
- les idées que les gens nous soumettront
- les potentiels patches qu'on intégrera (cf le github du projet)

Pour l'instant, je dois avouer qu'on s'est concentré sur un truc simple qui marche et qui fait ce pour quoi on en avait besoin et que "release early, release often" qu'il disait.

Et ça ressemble à quoi ?

Ça ressemble à peu près à ça, une fois identifié (on a fait 2-3 ajustements de dernière minute depuis) :

Capture tableau de bord artifact-listener.org

Où on se dit qu'il serait peut-être temps qu'il donne un lien

Le tout est sur https://www.artifact-listener.org/ .

Je vous laisse prendre un ticket, c'est chacun son tour.

Les commentaires et les questions sont évidemment bienvenus.

Note : on vient de le pousser en production et c'est la première communication qu'on fait sur le sujet, d'où le fait que ce ne soit pas super peuplé (enfin, on espère que c'est dû à cela).

Guillaume

  • # Joli boulot

    Posté par  . Évalué à 2.

    Très sympa !

    Comme j'utilise moi-même pas mal le Maven Central Repository mais pas depuis maven, je me suis posé une question :
    Qu'est-ce que ça couterait d'ajouter l'analyse des dépendances pour des projets qui utilisent d'autres outils de build compatibles (oui sbt, c'est à toi que je pense, même si tu n'es pas le plus simple pour ce genre d'analyse…). Est-ce que votre architecture permet d'ajouter plus ou moins facilement ce type de choses ?

    • [^] # Re: Joli boulot

      Posté par  (site web personnel) . Évalué à 2.

      Mon dieu, un premier commentaire positif sur un journal. Inquiétant :).

      Alors, architecture, c'est beaucoup dire… on a plutôt avancé en mode "faisons simple et on fera évoluer en fonction des besoins/idées" plutôt que concevoir un gros truc modulaire.

      Mais ça pourrait se faire oui. Par contre, je dois avouer que le pom.xml a l'avantage de s'analyser super facilement (on a juste utilisé jsoup pour le faire). Pour les autres fichiers, c'est souvent moins simple.

      En gros, si on nous fournit l'outil d'analyse, on pourra sans souci l'intégrer dans l'interface de notre côté.

      De notre côté, on a prévu de rester sur Maven encore un moment, le temps que l'outillage se mette au niveau.

      • [^] # Re: Joli boulot

        Posté par  . Évalué à 1. Dernière modification le 29 mai 2013 à 17:06.

        C'est sûr que couvrir sbt en entier imposerait une grosse machinerie, mais si on se limite à parser les fichiers .sbt dans un premier temps ça peut être simple aussi. Je regarderai ça à l'occasion…

        J'ai tout un tas d'idées qui me vient là sur une utilisation de votre appli, comme : et si je pouvais créer un projet avec ses dépendances via une API Rest (ou autre) depuis mon outil de build directement, ce serait super. D'une part parce que j'aurais réussi à placer plein de buzz words mais qui sont utiles ici en une seul phrase, et d'autre part ça déléguerait la complexité et l'hétérogénéité des analyses aux outils de build eux même…

        edit : typo

        • [^] # Re: Joli boulot

          Posté par  (site web personnel) . Évalué à 1.

          Les services Rest, on y viendra sûrement. Il faut juste arriver à voir ce qui peut être utile.

          Pour l'instant, ma priorité est d'arriver à enrichir l'information, notamment via l'ajout des release notes, annonces… C'est clairement une information relativement pénible à trouver quand on la multiplie par le nombre d'artifacts et le nombre de versions et qui a son importance quand on commence à envisager une mise à jour.

  • # Ça a l'air sympa

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    J'ai intégré quelques pom, on verra ce que ça donne.
    Ce serait cool de pouvoir tout ajouter d'un coup, cliquer 50 fois sur suivre c'est un peu long la première fois.
    La feature "regrouper les artifacts sous des projets" ce serait vraiment cool aussi pour retrouver les pom à mettre à jour

    • [^] # Re: Ça a l'air sympa

      Posté par  . Évalué à 1.

      La feature "regrouper les artifacts sous des projets" ce serait vraiment cool aussi pour retrouver les pom à mettre à jour

      Maven ne le fait pas déjà de base ? 

      $ mvn versions:display-dependency-updates
[...]
[INFO] The following dependencies in Dependencies are using the newest version:
[INFO]   com.clearspring.analytics:stream ............................... 2.3.0
[INFO]   com.google.guava:guava ........................................ 14.0.1
[INFO]   commons-cli:commons-cli .......................................... 1.2
[INFO]   joda-time:joda-time .............................................. 2.2
[INFO]   junit:junit ..................................................... 4.11
[INFO] 
[INFO] The following dependencies in Dependencies have newer versions:
[INFO]   org.apache.hadoop:hadoop-core ................. 0.20.2-cdh3u5 -> 1.2.0
[INFO]   org.apache.mrunit:mrunit ................... 0.8.0-incubating -> 1.0.0

      Le truc qu'il manque effectivement c'est le changelog & co vu que ce n'est pas dans les repo maven. Mais bon d'une manière générale tu connais tes dépendences, comment chacun gère ses releases et que tu as une approche optimiste ou pessimiste de l'upgrade selon le type du projet sur lequel tu bosses.

      • [^] # Re: Ça a l'air sympa

        Posté par  (site web personnel) . Évalué à 1.

        La feature "regrouper les artifacts sous des projets" ce serait vraiment cool aussi pour retrouver les pom à mettre à jour
        Maven ne le fait pas déjà de base ?

        Yep, Maven le fait de base mais c'est vrai qu'on pense rarement à le faire. D'où le fait qu'un petit push a du bon. En particulier quand on attend une correction de bug avec beaucoup d'impatience.

        Le fait de savoir qu'un artifact est utilisé par tel projet peut finalement aussi nous servir à faire le ménage.

        Mais bon d'une manière générale tu connais tes dépendences, comment chacun gère ses releases

        Ouais, je dois avouer que je fais quand même un tour sur les changelogs en général pour voir si ça vaut le coup de prendre le risque en fonction du moment et du temps qu'on a.

        Après, notre usage est sans doute un peu particulier vu qu'on maintient un socle avec plein de projets en dessous.

        • [^] # Re: Ça a l'air sympa

          Posté par  . Évalué à 2.

          Après, notre usage est sans doute un peu particulier vu qu'on maintient un socle avec plein de projets en dessous.

          J'ai fait les deux, d'être tout en bas dans des projets assemblant plusieurs centaines de modules, à être dans des petits projets où tu fais le punk vu que tu es ton seul utilisateur.

          Avoir une solution web est très bien, c'est une bonne initiative et je suis sur que beaucoup de gens y trouveront leur compte. J'y vois deux aspects, le push, et le côté dashboard. Je dis juste que les infos sont déjà là et faciles à extraire. Et que le problème est que les gens ne savent simplement pas s'en servir ou s'organiser.

          Après à chacun de savoir se servir de ses outils et de récupérer/structurer les informations dont il a besoin en faisant attention au syndrome " dashboard de dashboard de dashboard " et " je me fais spammer d'info alors que j'en ai besoin une fois tout les six mois et j'ai déjà une solution de pull ". J'ai aussi un peu l'impression qu'il y a deux produits différents. Le côté push, social & co est très bien sur le web. Mais pour avoir une vue synthétique de ses produits, ca a plus sa place en interne intégré aux autres outils.

      • [^] # Re: Ça a l'air sympa

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Quand tu bosses que sur un projet ouais, quand tu en maintiens plusieurs avec une centaine de dépendances au total, c'est pas facile de se souvenir pour toutes lesquelles sont utilisées dans quels projets.

        • [^] # Re: Ça a l'air sympa

          Posté par  . Évalué à 1.

          Ca change quoi ?

          La démarche est exactement la même. Tu n'as rien à te souvenir. De toute facon Maven est capable de te ressortir l'info au besoin, et ton système d'assemblage doit te claquer dans les mains si tu tombes sur un cas de conflit (attention à Maven qui souvent par défaut va laisser passer sans rien dire…)

    • [^] # Re: Ça a l'air sympa

      Posté par  (site web personnel) . Évalué à 1.

      J'ai intégré quelques pom, on verra ce que ça donne.

      Normalement, ça donne bien. On l'utilise depuis un bon mois de notre côté et ça m'a vraiment simplifié la vie. Le fait que ce soit simple et con fait que ça marche du coup.

      Ce serait cool de pouvoir tout ajouter d'un coup, cliquer 50 fois sur suivre c'est un peu long la première fois.

      Oui… En fait, on pouvait le faire avant qu'on me convainque de faire des boutons Ajax : on avait mis une case à cocher pour tout un bloc donné. On pourrait sans doute le refaire en Ajax aussi. Je le note.

      La feature "regrouper les artifacts sous des projets" ce serait vraiment cool aussi pour retrouver les pom à mettre à jour

      Vu qu'on extrait l'info du pom, on pourrait sans doute tagger les artifacts avec l'artifactId extrait du pom. Ca répondrait au besoin ?

      • [^] # Re: Ça a l'air sympa

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Vu qu'on extrait l'info du pom, on pourrait sans doute tagger les artifacts avec l'artifactId extrait du pom. Ca répondrait au besoin ?

        Ce serait très bien oui, avec possibilité de mettre à jour quand on rescan le pom ce serait juste parfait.

  • # proxy type nexus

    Posté par  . Évalué à 1.

    Bonjour,

    Dans ma boite on est qu'une trentaine alors on le sait quand l'equipe d'a coté a sorti un truc qui est dispo sur le dépot.
    Mais dans une grosse boite ça pourrai être utile pour prévenir les gens que la librairie qu'ils utilisent en interne viens d'être mise à jour.
    Donc est-ce que c'est possible de checker un proxy d'entreprise plutôt que (ou "en plus de") maven central pour avoir en plus les artefact développés en interne?

    • [^] # Re: proxy type nexus

      Posté par  (site web personnel) . Évalué à 1.

      Hello,

      Ca pourrait sans doute se faire. Pour l'instant, nous n'avons pas implémenté les API Rest de Nexus ou d'Artifactory comme sources de données. On risque vite d'avoir le souci de plusieurs artifacts non cohérents entre des repositories distincts et ça va vite compliquer l'interface, notre objectif étant vraiment au départ de faire un truc simple qui juste marche et qui permette en quelques clics d'avoir géré le plus gros.

      Par ailleurs, pour le besoin des grosses boutiques, je pense qu'il faudrait sans doute l'installer en interne car je vois mal une grosse boutique accorder la vision sur son repository interne à un outil externe.

      Guillaume

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.