Projuice : s'organiser tous ensemble

Bonjour,

Je viens vous présenter une idée qui me trotte dans la tête depuis maintenant des années : trouver une solution de gestion de projets qui s'adapte bien aux petites structures : communautés, PME, startups, … A vocation "projet informatique" et surtout : qui soit utilisable et intéressante pour tous les acteurs du projet et pas seulement les développeurs.

Constats

Etat de l'art

Aujourd'hui, les développeurs disposent d'excellents outils de tracking, presque de gestion de projet. Je ne vais pas les énumérer mais entre Redmine, Jira, Bugzilla pour le bugtracking, github/gitlab qui permettent de partager des sources mais aussi de gérer des tâches et les assigner.

Ces outils sont excellents mais sont destinés à des développeurs. En marge de ça, les logiciels de management sont également nombreux : depuis MS Project jusqu'aux solutions de travail collaboratif en ligne en passant par les solutions très épurées et qui font ce qu'on leur demande, comme Trello.

Bref, l'état de l'art est vaste, mais il est souvent complexe de trouver la bonne solution pour gérer un projet collaboratif "naissant mais qui prend de l'ampleur" ou tout simplement dans une petite structure.

Il manque bien souvent aux outils orientés "dev" la vision "produit". Normal, le livrable est symboliquement du code, souvent ces outils ont été conçus pour gérer des bibliothèques open source, ou autres. Parfois pour un produit, mais "au chausse-pied".

Les faits

Dans les faits, bien souvent les entreprises mettent en place un système d'issue-tracking. C'est la base, c'est incontournable. Dans les petites entreprises, bien souvent cet outil est cantonné aux développeurs, voire à l'équipe "support technique", qui vont éventuellement remonter des bugs dedans.

Dans ces petites structures, le suivi des issues est donc très majoritairement assuré par les équipes de développement, voire de R&D. Et ça se comprend, on y discute technique, implémentation, l'outil n'est pas nécessairement utilisable par des gens d'autres métiers.

Pourtant, quand une réunion se profile, il n'est pas rare de voir des petits rapports imprimés en A4 provenant de l'issue-tracker. Et pour cause, ça permet d'avoir une vue sur le travail en cours.

En marge de cela, chaque "département" (si on peut dire ça pour une petite structure) va adopter ses propres outils pour s'organiser. De la feuille Excel à MS Project, en passant par Trello, la TODO list papier, le Google Doc pour les spécifications, Outlook/Google calendar pour les milestones.

C'est compréhensible, ça n'en reste pas moins un peu dommage.

L'objectif

L'idée est donc de concevoir un outil "méta", par-dessus un système d'issue-tracking, comme il en existe déjà. Avec pour objectif plutôt complexe (voire utopique) de contenter "tout le monde" (comprendre : tous les acteurs du projet)¹.

Il est essentiel de fournir à qui que ce soit dans l'entreprise, le moyen de contribuer et surtout de mesurer ses tâches, sa charge de travail, son degré d'implication et l'état d'avancement du projet en fonction du rôle qui l'occupe dans l'entreprise.

Il me semble que c'est le point bloquant concernant le manque d'adoption de ces outils.

En marge de cela, on peut remarquer que même dans de petites structures ou des communautés comme ici sur ZdS, un workflow se détache souvent. Même pour les gens qui se veulent "agile voire bordélique" (c'est du "déja entendu"), un processus de release est nécessaire. Même pour un projet personnel.

Les éléments "fondateurs" du projet sont donc les suivants :

• l'issue-tracking doit rester au niveau de ce qu'elle est dans d'autres outils type Redmine, JIRA, même si elle est plus simple, on ne doit pas perdre en fonctionnalité majeure

• quel que soit mon rôle, je dois retrouver mes petits, et ne pas être submergé d'informations qui ne m'intéressent pas

• je dois pouvoir échanger des documents provenant de sources externes. Sans aller jusqu'à la GED, je dois pouvoir importer des psd, des Google Docs, des wireframes, des fichiers Office

• je dois pouvoir échanger au maximum dans l'outil afin d'éviter d'envoyer des emails que je devrai trier par la suite. Que je sois commercial, développeur, CEO, l'outil doit me permettre de centraliser les informations échangées dans un soucis de pérennité.

• je dois être notifié quand quelque chose m'intéresse et uniquement par ce qui m'intéresse. Si je suis commercial, je suis intéressé de savoir qu'une fonctionnalité que mes clients attendent et que j'ai demandée est poussée en prod, pas qu'un bug mineur est résolu.

• l'interaction avec d'autres outils (intégration continue, …) semble incontournable sur le long terme. Il est donc essentiel de reposer sur des APIs. Comme on s'adresse essentiellement à des gens de l'informatique, ils seront très certainement intéressés et à même de développer une multitude de plugins ou outils complémentaires si besoin est. L'API REST semble s'imposer pour développer l'interface "de base" et permettre des intégrations externes simples.

Bref, ce qui se détache de cela c'est une "vue à facettes" du projet.

Boule Vue à facettes

C'est le point de difficulté majeur. Déterminer qui intervient dans un projet et quand. Il faut rester évolutif (voire configurable) sur ce plan. Pour l'instant, voici les "rôles" identifiés :

• Le "rapporteur" (comm', commerciaux) (ou carrément : le client final lui-même)

  • en lien avec le client final
  • intéressé par le fonctionnel uniquement et très grossièrement (les détails ne techniques ne l'intéressent pas, et même certains détails fonctionnels)
  • en entrée : c'est l'entrée. demande des fonctionnalités, rapporte des bugs
  • attentes : le produit fini, rien d'autre

• la MOA ou, plus génériquement : L'équipe de spécification. Qui se charge de spécifier les nouvelles fonctionnalités ou les évolutions de l'existant. (cf. les ZEP ici, c'est exactement l'idée). + ergonomes + designers

  • spécifie
  • en sortie : cahier des charges, cahier de "recettes"
  • (uniquement) intéressée par l'aspect fonctionnel

• L'équipe R&D, équipe de développement + infra (équipe d'administration système&réseaux)

  • en entrée : spécifications et cahier des charges
  • recherche des solutions
  • réalise
  • en sortie : prototype, PoC, produit recettable
  • intéressée par le fonctionnel pour l'implémenter, discussions techniques

• L'équipe de QA

  • en entrée : un produit recettable
  • en entrée : une "grille de QA" adapté aux attentes (à granularité fine : on peut tester un bugFix, une nouvelle fonctionnalité, ou une release de façon globale avant qu'elle ne soit poussée en production).
  • en sortie : un rapport de tests, Go/NoGo, Ship/NoShip et des notes de QA

Voilà pour les acteurs & rôles définis aujourd'hui. En l'état c'est jouable et ça me semble s'adapter à peu près (même si ce n'est évidemment pas la panacée) à ce qu'on peut trouver.

Vous noterez que bien qu'on ait défini des rôles, on voit déjà un workflow se dessiner.

Le modèle

Workflow

Dans l'exemple précédent, le workflow suivant se dégage :

Demande -> Spec' -> Réalisation -> QA -> Release -> Notification au demandeur

Workflow qui peut bien évidemment boucler à chaque étape.

"Par défaut" pour l'organisation qui j'ai définie plus haut (qui me semble convenir à une PME, un projet perso, une organisation comme ZdS), chaque "Feature" (ou "Issue") suivrait ledit workflow. A moins qu'on en définisse un spécifique à la feature en question. (sauter l'étape spec' si on parle d'un bugfix par ex.).

Milestones

A peu près tout le monde sait ce que sait, je ne m'étends pas là-dessus. Il est nécessaire qu'elles soient au centre du projet. dueDate optionnelle pour plus de flexibilité, l'objectif étant de les voir, de voir pourquoi elles sont bloquées, et pourquoi une milestone a avancé beaucoup plus vite qu'une autre…

Bref, objectifs : pour filtrer, pour agréger, pour avoir les bons reports (e.g. on fait des tests de non-regression sur une milestone en entier)

Issue

Terme générique (et mauvais, et à changer) pour désigner :

• une correction de bug

• une évolution de l'existant (enhancement proposal)

• une nouvelle fonctionnalité

C'est l'élément central de Projuice. (au même titre que github par exemple).

Une issue est donc consultable par tous les acteurs, la vue est adaptée au rôle occupé.

Une issue possède un workflow, dans ce workflow on retrouve différentes tâches. Soit automatiques (QA, …) soit ajoutées manuellement (penser à modifier le fichier machin, il manque une icône bidule à designer, …). Chaque tâche est assignée.

Certaines tâches peuvent être effectuées en parallèle. Je ne rentre pas trop dans le détail (on va pas aller jusqu'à Gantt, Pertt ou autres représentation, l'objectif est KISS, même si ça se complique un peu).

Une issue peut être liée à une milestone.

Meetings

Dans toute structure, il existe des réunions.

Parfois elles se font sur le pouce, sans ordre du jour très bien établi, parfois comme dans le cas des ZestMeetings elles sont très cadrées.

Pourtant, il est souvent pénible de :

• préparer l'ordre du jour (en allant pêcher les liens utiles à propos des sujets discutés) et norifier les participants (potentiels)

• rédiger un compte-rendu et notifier les absents qui pourtant seraient intéressés par le contenu discuté.

L'idée ici est de référencer des issues depuis les meetings et vice-versa (les développeurs auront vu un ManyToMany là-dedans). Afin de :

• préparer très simplement l'ordre du jour : lorsque je prépare (crée) un meeting j'ai la liste des issues et je pioche dedans

• inviter des participants automatiquement et les notifier (ceux qui travaillent sur les issues en question) + d'autres si besoin

• rattacher automatiquement le compte-rendu au contenu discuté (depuis l'issue je sais qu'elle a été discutée dans le meeting X et je peux lire le compte-rendu) : l'information est pérennisée et accessible depuis plusieurs points d'entrée

Labels

Au même titre que ceux de github, ils sont là pour améliorer la recherche, ou pour repérer visuellement des issues ou des tâches.

Je passe rapidement : ce sont des tags, basiques, on peut rechercher / filtrer, y'a des couleurs, comme dans github. Pas la peine de s'étendre là-dessus.

NB : WIP mais si vous avez des remarques sur ce que vous attendriez d'un tel outil je prends tout (au risque de me noyer mais je le prends).

NB² : si vous êtes intéressés par l'aspect technique, je peux détailler certains choix dans le message suivant.

Ou irai rentre une "equipe design" par exemple celle qui te ferait tes petites icônes, tes psd et autres compos ? Je suppose quelque part autour de R&D ? Car c'est un rôle qui n'est pas "technique" (au sens développeur du terme) mais représente un prérequis pour ces dernier. Un graphiste doit savoir qu'on l'attend et doit avoir un retour de la suite du process en cas de souci, mais une fois sa compo faite il est pas forcement intéressé par tout les commits de l’intégrateur.

EDIT : en fait en relisant je vois que ce sera juste une histoire de bien filtrer avec les "issues"

PS, en francais la meilleure traduction de "issue" sera "Ticket" je pense

Je suppose quelque part autour de R&D ?

Je l'aurais mis dans l'équipe de spécifications, dans les dernières tâches.

Pourquoi ?

Tu as énoncé quelques faits (les détails techniques ne l'intéressent pas) et au même titre que l'équipe de spécification, il va être en relation avec les développeurs et les développeurs attendent des livrables de sa part (en amont).

Après non, c'est pas une histoire de filtrer avec les issues, en tout cas je ne le vois pas comme ça. Là on est en train de parler d'une tâche (dessiner des icônes) à l'intérieur d'une issue. Au même titre que dessiner l'écran, ou faire un PoC. Qui font toute partie de l'issue "changer la page d'accueil" (swidh ? ).

Soit on en fait un rôle à part. Pourquoi pas mais je ne suis pas sûr que ce soit bien nécessaire, notamment, il va être impliqué dans des issues qui n'ont rien à voir avec du dev (une plaquette commerciale ?) et qui pourtant va passer par la case : demande (équipe de comm'), réa (son étape à lui), QA, release.

Du coup pour son "rôle" au sens "quelle vue on lui présente" pour moi ça se rapproche de l'équipe MOA. On attend des livrables de sa part (l'équipe de comm' comme sur ZdS, ou les developpeurs comme sur ZdS) mais les détails techniques ne l'intéressent pas.

Ma présentation n'est sûrement pas encore assez claire, je vais essayer de mieux expliquer.

Juste une petite update pour dire que j'avance mais que je me concentre pour l'instant sur des trucs un peu chiants mais qui n'ont pas énormément d'intérêt fonctionnel, à savoir la mécanique de login et, par extension, un petit bout de framework web.

Le tout pour pouvoir pusher ça sur github sans avoir mes propres tokens github qui traînent dans le code.

Fait :

• Aperçu MD
• Import d'issues github en tant que fonctionnalités, avec les milestones, les utilisateurs, les labels associés. Créés uniquement s'il n'existent pas déjà dans le projet. Ce qui permet de faire des imports incrémentaux depuis github (donc des synchros github, en fait)

Milestone 1 : Code "montrable" et publiable sur github, dueDate : dimanche.

Après je commence à bosser sur (dans l'ordre) :

• les organisations / entités du projet (les formaliser "par défaut", mais rester souple pour que les gens puissent définir leurs propres entités)

• la mécanique de workflow pour suivi d'une fonctionnalité (avec allers-retours entre deux entités)

• les meetings avec génération automatique d'ordre du jour et compte-rendu automatiquement lié aux fonctionnalités discutées

• la mécanique de notification temps-réel

En attente, j'aurai pensé à des livrables intermédiaires (screnshots par exemple, pour savoir si ça va me plaire) Source : Javier

Très juste, merci.

J'aurai séparé les deux profil. Le dev et l'infra c'est clairement deux profil différent, même si dans certains cas, il pourrait faire les deux, il faudrait pouvoir désigner quelqu'un comme uniquement infra.

Deux organisations, deux profils différents oui, mais la même "vue" d'une issue. Les détails techniques, le code, etc. En entrée des specs, c'est vrai qu'en sortie le livrable n'est pas tout à fait le même.

A creuser, c'est pas clair de mon côté non plus.

Je ne trouve pas la prise en charge des itérations dans le Workflow tel que tu le définis. Une Spécification peut donner lieu à plusieurs lotissements. Il faudrait donc pouvoir "découper" une spécification, et définir ses jalons. Tout en étant capable de la suivre jusqu'à son terme.

C'est une remarque très intéressante.

Il y a une notion d'itération, mais effectivement pas dans le sens où tu le décris. On peut "revenir en arrière" mais effectivement il manque la notion de fonctionnalité évolutive. Qui passe par une ou plusieurs étapes plusieurs fois.

Y'a plusieurs trucs :

• on spécifie en plusieurs fois (et on a besoin donc de plusieurs jalons) (l'étape contient donc uniquement des sous-étapes jalonnées)

• on spécifie ET ON PASSE A LA SUITE pendant qu'on spécifie la suite et là ça se complique

On devrait pouvoir créer des issues privés pour des profils particuliers. Je pense ici aux issues de types "failles de sécurité", etc.

Oui, c'est à réfléchir pour des versions futures, je note, même si clairement pas prioritaire.

J'irai même jusqu'a dire qu'une issue doit être reliée à un workflow particulier, ce qui signifie que tu dois pouvoir gérer différents workflow. Dans les workflow, on peut parler du workflow d'un bug majeur, d'un bug mineur, d'une feature mineure, d'une feature majeure, etc. Bref, une zone d'administration de mes workflows qui me permette de décrire quel sera le cycle de vie de chaque type d'issue.

La zone d'administration des workflows c'est clairement prévu.

En créant une issue, on choisira le workflow (avec potentiellement un workflow par défaut). Mais oui, bien sûr, il y aura une "bibliothèque" de workflows. Y'a pas encore de "type d'issue" défini, mais à long terme ça pourrait exister et dans ce cas on pourrait tout à fait faire l'association entre les deux.

Pour finir, je pense que ce qui serait une vraie Killer feature seraient des stats sur les travaux. En combien de temps en moyenne je traite chaque type de workflow (bug, features, etc) ? Quelle étape du workflow est plus longue (QA, dev, etc.) ? Est-ce que cette goulot est généralisée sur tout mes type de workflow (on met presqu'autant de temps de QA sur les bugs que sur les features) ?

Oui, à 100%.

J'ai des écrans de reporting dans la tête depuis que j'ai eu l'envie de me mettre sur ce projet. C'est même assez difficile d'avancer sur d'autres trucs que ça en fait. C'est vraiment ce que j'ai envie de faire.

Le but du jeu c'est :

• web, parce que l'install d'un soft rebute pas mal de gens maintenant, et l'objectif c'est des PME, des projets persos ou communautaires, bref, on peut pas dire "installez le soft bidule"

• non-hébergé (comprendre : tu l'installes chez toi sur TON réseau d'entreprise) j'ai pas les reins pour faire ça en ligne

• léger et scalable : si tu l'installes chez toi, et vu qu'on vise des PME, l'idée c'est que tu puisses te servir d'une vieille machine. Idem, si c'est pour une communauté, c'est chiant à héberger, l'objectif c'est que n'importe qui puis l'héberger chez lui. Par contre le jour où tu montes en besoin, nb utilisateurs etc.

• simple et le moins de dépendances possibles : y'a déjà une BDD relationnelle et c'est presque déjà trop. Je vais essayer de faire en sorte qu'on puisse choisir celle qu'on veut (i.e. ça fonctionne sous Pg, MySQL, Oracle) avec un processus d'install simplifié. Pas envie de faire installer un JBoss, Tomcat, ou quoi que ce soit aux gens en plus de la BDD, ça m'embête. J'ai pensé à le packager en WAR/EAR mais ça m'ennuie aussi :\

• supporte les websockets, j'ai pas envie qu'on passe son temps à rafraîchir les pages d'une part, pas envie de faire du polling toutes les secondes d'autre part. Enfin, j'apprécierai avoir une version légère sous mobile

• enfin, j'ai un peu envie de progresser sur certaines technos, donc mon choix est (subjectivement) drivé par ça…

Pour toutes ces raisons, j'suis parti sur Vert.x.

Surtout pour la légèreté, la scalabilité (lancer N instances de façon totalement transparente) et le support des websockets.

En écrivant les modules en Groovy parce que le support des Closure permet une écriture moins pénible de code asynchrone (I/O websockets notamment, communication par EventBus). Et aussi parce que j'ai besoin de progresser dans ces technos.

Il lui manque un vrai framework web cependant (déclarer des routes par annotation par exemple). Même si Yoke existe.

Mais depuis le temps que je zone entre Struts, Spring, Seam, Rails, Grails, bah je me dis que je peux ptetre à arriver à en faire un bon, simple et léger. (pas du premier coup, mais c'est l'occaz d'essayer). Ça fait clairement chier de réinventer la route, mais j'ai bon espoir de "donner" le framework à la communauté de Vert.x, Yoke est pas mal, mais il manque un "Rails-Like" à Vert.x.

Côté ORM c'est Hibernate sans surprise. J'suis parti sur postgres mais je voudrais ne pas être dépendant de fonctionnalités spécifiques à un SGBD (et je devrais y arriver).

Voilà pour l'inventaire. Merci de ton intérêt et tes remarques.

Tu sais quoi ? ça me met l'eau à la bouche.

Bon courage pour le projet. Je le suivrait autant que possible, et je passerai même souvent te faire des PRs le jour ou les sources seront en ligne.

NB : je me pose très fortement la question d'utiliser JBPM pour définir les workflows.

J'ai pas bossé avec depuis longtemps, mais j'ai quand même la très forte impression que ça serait bien adapté à mes besoins.

Update :

Je vais délaisser un peu le côté framework web (en gros : la machinerie) et le laisser en l'état, c-à-d : fait le taff, pas propre du tout.

Pourquoi ? Vert.x 3.0 (actuellement en développement, bêta fin janvier) amène un lot énorme de fonctionnalités et notamment le fait de pouvoir écrire facilement une API REST. Ça tombe bien, c'est ce que fait mon framework.

Du coup, je vais me concentrer sur le fonctionnel, la représentation des données et le front, en attendant la sortie de Vertx 3.0.

Entre temps, j'ai contacté l'équipe de Vert.x en leur exposant rapidement ce que j'avais fait et "sounds cool" du coup je devrais être amené à travailler sur le nouveau REST framework (l'officiel)

Donc le projet va avancer, mais dans une autre voie que celle que j'avais imaginée. Mais c'est ptetre pas plus mal, je vais avancer dans le concret de MON projet plutôt qu'essayer de construire un framework.

Je ne suis pas sur d'avoir bien compris la phrase, il manque un bout.

Oui j'ai édité je crois.

En gros quand j'ai vu ce qu'ils faisaient pour la prochaine version je les ai contactés en leur disant "mais je fais quasiment la même chose : regardez". Ils m'ont dit "Sounds cool ! Would you be interested in joining Vertx 3.0 development team". Donc mon taff n'est pas perdu (même s'ils ont pris une approche un peu différente).

Du coup c'est plutôt bon pour mon projet. Je vais pouvoir me consacrer au fonctionnel et surtout au front en attendant la sortie d'un VRAI framework REST "standardisé" par Vert.x, dans lequel je serai impliqué et développé notamment par des mecs qui ont bossé sur Resteasy.

Ah c'est une bonne nouvelle alors. On va avoir des screens plus vite que prévu alors.

Eh ! Du coup, ça m'intéressait ce petit projet. Des nouvelles ? :3

Après avoir contribué puis mis au point un espèce de framework MVC pour Vert.x pendant de longs mois, (cf. Vertx Apex) j'ai recommencé à travailler dessus lundi

Curieuse coïncidence que tu déterres le sujet après tant de temps aujourd'hui !

J'ai désormais toutes les briques techniques dont j'ai besoin. Je reprends peu à peu les spécifications exposées dans ce sujet.

Le hasard fait bien les choses il faut croire.

Héhé. C'est justement parce que j'étais tombé sur ton profil Github et que j'avais vu que tu bossais en effet sur un tel framework que j'ai repensé à ton projet.

Je me doutais que ce n'était pas fortuit.

Comment t'es tombé sur mon profil GitHub par curiosité ?

En errant sur les ZEP et plus particulièrement celle sur l'éditeur ZMarkdown du site, il y avait un lien vers ton implémentation avec Aperçu en direct et ce lien menait à ton profil Github. Donc c'est quand même un peu fortuit o/.

Sans vouloir me la jouer "à la Flare" c'est absolument pas comparable, mais un petit point technique, pour le plaisir.

Voilà à quoi ressemble le framework web en utilisation concrète :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81

package io.projuice.controllers.api;

import io.projuice.WebVerticle;
import io.projuice.model.Project;
import io.vertx.ext.apex.RoutingContext;
import io.vertx.hibernate.results.ListAndCount;
import io.vertx.mvc.annotations.Controller;
import io.vertx.mvc.annotations.Path;
import io.vertx.mvc.annotations.Throttled;
import io.vertx.mvc.annotations.methods.GET;
import io.vertx.mvc.annotations.methods.POST;
import io.vertx.mvc.annotations.methods.PUT;
import io.vertx.mvc.annotations.params.Param;
import io.vertx.mvc.annotations.params.PathParam;
import io.vertx.mvc.annotations.params.RequestBody;
import io.vertx.mvc.context.PaginationContext;
import io.vertx.mvc.controllers.impl.JsonApiController;

@Controller("/api/1/projects")
public class ProjectApiController extends JsonApiController {

  @BeforeFilter
  public void checkCredentials(RoutingContext context, @Param("token") String token) {
      if (token == null) {
          context.fail(401);
          return;
      }
      context.next();
  }
  
  @Path("")
  @POST
  @Throttled
  public void createProject(RoutingContext context, @RequestBody Project project) {
      WebVerticle.hibernateService.withinTransaction(entityManager -> {
          entityManager.persist(project);
          return project;
      }, result -> {
          resultAsPayload(context, result);
      });     
  }
  
  @Path("/:projectId")
  @GET
  public void getProject(RoutingContext context, @PathParam("projectId") Long projectId) {
      WebVerticle.hibernateService.withEntityManager(entityManager -> {
          return entityManager.find(Project.class, projectId);
      }, result -> {
          resultAsPayload(context, result);
      });
  }
  
  @Path("/:projectId")
  @PUT
  public void updateProject(RoutingContext context, @RequestBody Project project) {
      WebVerticle.hibernateService.withinTransaction(entityManager -> {
          entityManager.merge(project);
          return project;
      }, result -> {
          resultAsPayload(context, result);
      });
  }

  @Path("")
  public void list(RoutingContext context, PaginationContext pageContext) {
      WebVerticle.hibernateService.withEntityManager(entityManager -> {
          ListAndCount<Project> result = new ListAndCount<Project>(Project.class, entityManager);
          result.queryAndCount(pageContext.firstItemInPage(), pageContext.lastItemInPage());
          return result;
      }, result -> {
          if (result.succeeded()) {
              ListAndCount<Project> listAndCount = result.result();
              pageContext.setNbItems(listAndCount.count());
              setPayload(context, listAndCount.result());
              context.next();
          } else {
              context.fail(result.cause());
          }
      });
  }
}

• Donc en gros on trouve des annotations "à la resteasy" pour déclarer ses routes HTTP, avec des filtres et une méthode par chemin au sens HTTP
• Un driver asynchrone pour Hibernate
• La pagination ( /projects?page=2&perPage=100 ) injectée pépère en paramètre de la méthode
• le contenu de la réponse marshallé en json automatiquement
• le contenu de la requête (POST, PUT) lu, converti en objet et injecté en paramètre à la méthode automatiquement

J'avance sur le projet en lui-même, mais ça simplifie immensément le boulot.