:: Enseignements :: ESIPE :: E4INFO :: 2022-2023 :: Java Avancé ::
[LOGO]

Projet de Java Avancé INFO 2 - 2022

Exercice 1 - Clout Metrics

Le but du projet Clout Metrics est d'écrire une application web qui analyse un repository git (par exemple sur github ou gitlab) et affiche différentes métriques et les badges du projet.
L'application Clout Metrics est composée d'un back-end écrit en Java offrant différents services REST permettant d'accéder aux données des métriques et badges d'un projet et d'un front-end écrit en JavaScript affichant les métriques sous forme de graphe et autres gizmos visuels.
L’application doit permettre...
  • ... d'ajouter un nouveau repository. Il n'y a pas de notion d'utilisateur, tout le monde peut ajouter un repository
    Le repository est alors analysé et les différentes métriques sont calculées. Attention, comme calculer les différentes métriques peut prendre du temps, il faut que visuellement, l'utilisateur voit les métriques déjà calculée et celles qui sont en cours de calcul.
  • ... de mettre à jour les métriques et badges d'un projet de façon incrémentale, dans ce cas, les métriques doivent être recalculées par rapport aux nouvelles informations. Attention, le recalcul doit être incrémental, vous ne devez pas jeter les métriques existantes et tout recalculer, mais mettre à jour les métriques.
  • ... d'afficher un tableau de bord avec les différentes métriques pour un repository git ainsi que les badges associés à chaque auteur.

En termes d'interface graphique, votre application doit être composée de trois écrans :
  • Le premier écran sert d'écran d'accueil et affiche l'ensemble des repositories disponibles. Il doit permettre d'ajouter un nouveau repository ou de mettre à jour un repository ainsi que l'ensemble des auteurs des différents projets. Pour cette écran, uniquement les informations essentielles d'un repository doivent être affichées (au moins : le nom du projet, l'URL du repository git, la date d'ajout du repository, la date du dernier refresh , si un refresh des métriques est en cours, avec une barre de progression si possible !) et pour chaque auteur, le nombre de projet auxquels il a participé ainsi que le projet principal sur lequel il a contribué et les badges pour ce projet.
  • Un seconde page affiche les métriques du repository et les badges des auteurs sous forme d'un tableau de bord. Vous trouverez des exemples visuels de métriques ici : https://github.com/lowlighter/metrics
  • La troisième page indique, pour un auteur, chaque projet auquel il a contribué avec les badges pour chaque projet.

Voici la liste des métriques qui vous sont demandées :
  • Le noms des auteurs avec, pour chacun, le nombre de lignes de codes contribuées (cf git blame) ordonnées du plus gros contributeur au plus petit.
  • Les langages de programmation utilisés, en pourcentage. Pour simplifier, on utilise l'extension du nom de fichier pour savoir quel est le langage d'un fichier.
  • L'outil de build utilisé : make, ant, maven, gradle, cargo, bazel, sbt, etc...
  • La licence utilisée, en vert si la licence est Open Source.
  • La liste des dépendances externes (au moins pour Java) pour lesquelles il existes une version plus récente, triées par date de parution des librairies, de la plus ancienne à la plus récente.
  • Le ratio entre le nombre de lignes de documentation (type javadoc) et le nombre total de lignes de code (commentaire pas de doc exclu).
  • Une métrique intéressante que vous êtes seuls à proposer.

Chaque auteur peut recevoir un ou plusieurs badges indiquant un travail sur une partie particulière du projet.
Voici la liste des badges qui vous sont demandés :
  • Le builder décerné à l'auteur qui à modifié le plus les fichiers de build.
  • Le doc(tor) décerné à l'auteur qui a fait le plus de documentation, en regardant les fichier .md et commentaires dans le code.
  • Le devops décerné à l'auteur qui à modifié le plus les fichiers d'intégration continue (en regardant les fichiers des Github Actions, de TravisCI et de Circle CI) ainsi que les fichiers liés à docker (Dockerfile, docker-compose.yml).
  • L'architect décerné à celui qui a le plus modifié les interfaces et le fichier module-info.java en Java.
  • et au moins deux autres badges spécifiques à votre projet.

Technologies à utiliser :
  • Vous devez utiliser Maven comme outil de build et IntelliJ comme IDE, et la version 19 de Java.
  • Pour tester vos services REST, vous pouvez utiliser Postman ou tout autre client capables de faire des requêtes REST.
  • Les tests unitaires Java doivent être effectués avec JUnit 5.9.1, vous pouvez vous référer au guide d'utilisation.
    Chaque classe Java doit avoir une classe de test correspondante (pour au moins 80%) du projet.
  • Pour la sérialisation/dé-sérialisation JSON des requêtes, vous utiliserez une API de parsing JSON Jackson 2.13.4.2
  • Pour l'extraction de "truc"(TM) dans le code source, vous utiliserez des expressions régulières avec le package java.util.regex.
  • Pour s'interfacer avec Git, vous utiliserez Jgit 6.3.0.202209071007-r.
  • Pour discuter avec le resolver de dependency de Maven , il y a une API https://maven.apache.org/resolver/ (la version 1.8.2), ce projet a été commencé par Eclipse puis récupérer par la fondation apache, la doc est toujours sur le site d'Eclipse sous le nom du projet Aether (wiki.eclipse.org/Aether).

Pour implanter les différents services REST, votre application doit utiliser une des technos (c'est moi qui choisi pas vous) ci-dessous.
Pour le mapping Object / Relational, c-a-d voir une ligne d'une table de BDD comme un objet Java : il y a deux implantations, une à base d'Hibernate qui peut être utilisée directement soit par l'intermédiaire de la spécification JPA (Java Persistance API) ; et une à base de JDBI.
Pour le front-end web, vous avez besoin d'un framework graphique
Note : le front-end doit être "buildé"" aussi en utilisant Maven (un seul POM pour front et le back) vous aurez peut-être besoin de plugin Maven specifique pour cela.
Note2: vous avez besoin de npm pour la partie build mais pas à l'exécution ! Vous pouvez, de plus, utiliser une librairie spéciale pour la gestion des graphes pourvu quelle soit adaptée à votre framework (pas de react-graph si vous devez utiliser svelte).
Pour vous aidez à avoir de belles pages, vous allez aussi utiliser une bibliothèque qui vous aide pour la partie CSS
L'application a besoin d'une base de données mais vu le volume de données, pas forcément d'une "vraie" base de données ; nous utiliserons donc des bases de données embedded.
L'intérêt d'une BDD embedded est qu'elle est prête à l'emploi directement à partir d'un jar.
Il y a deux façons d'accéder à une BDD en Java, en utilisant le Driver JDBC ou le DataSource JDBC. On vous demande d'utiliser le DataSource car la gestion des connections à la BD est automatique. Attention, H2 et SQlite peuvent être utilisés aussi comme des BDDs classiques extérieures à l'application, mais ce n'est pas ce qui nous intéresse ici, on veut la version embedded !

REST API documentation :
Nous allons documenter l'API REST de votre back-end en utilisant le format Open API 3.
Note : il y a deux façons d'utiliser Open API, soit on l'utilise comme un générateur qui génère le squelette de l'API soit dans l'autre sens, on extrait les valeurs des classes Java. On va utiliser la seconde version, comme cela, la documentation de l'API sera toujours à jour avec le code.

Sécurité :
  • Pas de HTTPS pour ce projet (c'est mal) mais c'est pour vous aider à débugger !
  • Les entrées des services web au niveau de l'URL ou de la partie JSON doivent être validées et les sorties doivent être "escapées" pour éviter les injections de code.
  • Il n'y a aucune raison que le login/mdp de la BDD soit en dur dans votre code !

Binômes avec les technos qui doivent être utilisées :
  • BABILLON - BELIN
    Quarkus Reactive - Quarkus Hibernate with panache - SQLite - Svelte - Bulma
  • BADAROU - COMMUNIAU
    Spring Boot MVC - Spring Data JPA - SQLite - Angular - Bootstrap
  • BEAURY - VEXIAU
    Spring Boot MVC - Spring Data JPA - H2 - Vuejs - TailWind
  • COSTANDI - DAO
    Quarkus - Quarkus JPA - H2 - React - Tailwind
  • DONNE - TOSTAIN
    Helidon SE - Helidon DBClient - H2 - Vuejs - Bootstrap
  • HUMBERT - WEISSE
    Micronaut - Micronaut JPA - SQLite - React - Bootstrap
  • LATCHOUMAYA - VELU
    Spring Boot Reactive - Jdbi - H2 - Angular - Tailwind
  • PEREIRA - ROMAS
    Micronaut Reactive - Micronaut JPA - H2 - React - Bulma
  • SNACEL
    Helidon Nima - Helidon DBClient - SQLite - Svelet - Tailwind

Calendrier des rendus.
Soutenance intermédiaire (béta) :
Toutes les parties de l'architecture doivent être présentes et pouvoir communiquer entre elles.
Il peut y avoir des bugs, c'est pas grave. Fonctionnellement, seule la partie incrémentale du calcul des métriques et des badges n'est pas demandée.
Description des tests (TODO !)
Soutenance finale :
TODO !

Pour vous aider, si vous ne respectez pas les indications de "sudden death" suivantes, votre projet sera considéré comme mort et noté 0.
Pour la partie Java, le programme doit être écrit en utilisant correctement les différents concepts vus lors du cours de Java Avancé (sous-typage, polymorphisme, lambdas, classes internes, exceptions, types paramétrés, annotations, collections, entrées/sorties).
  • Votre projet ne doit pas utiliser une technologies qui n'est pas l'une de celles requises pour votre binôme.
  • Il ne doit pas y avoir de warnings lorsque l'on compile avec javac -Xlint:all.
  • Dans un module, les packages d'implantation ne doivent pas être exportés et requires transitive doit être utilisé là où c'est nécessaire.
  • Il ne doit pas y avoir de raw types, de @SuppressWarning non justifié, de cast non justifié.
  • Le principe d'encapsulation et la programmation par contrat doivent être respectées.
  • Il ne doit pas y avoir de champs ou méthodes protected.
  • Il ne doit pas y avoir d'instanceof/if...else sur des types là où il est possible d'utiliser le polymorphisme ou le pattern matching.
  • Chaque interface devra être nécessaire.
    Une interface possède 0 ou 1 méthode (sinon justifiée).
  • Aucune classe abstraite ne doit être publique ou utilisée comme un type.
  • Chaque méthode devra être appelée (pas de code mort).
  • Aucune méthode ne doit faire plus de 10 lignes sans une vraie justification.
  • Il est interdit d'utiliser des champs statiques typés par un objet (pas de variables globales), seules les constantes (static final) de type primitif sont autorisées (et utiliser l'injection de dépendance SVP).
  • Le fichier POM.xml ne doit pas contenir de dépendances non listées dans ce document où ayant une autre version que la version demandée (à part les dépendances de dépendances).

© Université de Marne-la-Vallée