Vidocq Documentation

Vidocq Runtime hérite directement des TCK passés par les briques fondatrices et expose ses propres runners pour les TCK MicroProfile. Cette page consolide l’état de conformité.

Vue d’ensemble

TCK État Détails

Jakarta REST 4.0 (Core Profile)

Vert

via Cassini — voir aussi vidocq/TCK.md

Jakarta Servlet 6.1

~90 %

via Foy — runner vidocq-servlet-chappe-tck-runner

Jakarta JSON-P 2.1

Vert

via Champollion

Jakarta JSON-B 3.0

Vert

via Champollion

CDI 4.1 Lite

774 / 774

via Vauban

MicroProfile Config 3.x

Planifié

extension vidocq-runtime-config-extension en cours

MicroProfile Health 4.x

Planifié

extension vidocq-runtime-health-extension en cours

MicroProfile Metrics 5.x

Planifié

extension vidocq-runtime-metrics-extension en cours

MicroProfile OpenAPI 4.x

Planifié

extension vidocq-runtime-openapi-extension en cours

MicroProfile JWT Auth

Planifié

jalon ultérieur

TCK Jakarta hérités

Vidocq Runtime ne ré-exécute pas les TCK Jakarta : ils sont validés par les briques sous-jacentes. Les runners suivants couvrent l’écosystème :

  • cassini-tck — Jakarta REST 4.0

  • foy-tck / vidocq-servlet-chappe-tck-runner — Jakarta Servlet 6.1

  • champollion-tck — JSON-P 2.1 + JSON-B 3.0

  • vauban-tck-runner — CDI 4.1 Lite (774/774)

Tous sont volontairement hors-reactor (POM modelVersion 4.0.0 standalone, sans <parent>). La raison est documentée dans le CLAUDE.md du workspace : le ClasspathWorkspaceReader de ShrinkWrap Resolver 3.3 (transitive du TCK officiel) repose sur maven-resolver 1.9 et ne sait pas parser les POMs Maven Model 4.1.0 utilisés dans Vidocq.

Conséquence opérationnelle : ces TCK se lancent toujours via leur script shell dédié, jamais via mvn -pl.

cd vidocq-runtime-rest-cassini-tck-runner
./run-official-tck-restful-4.0.sh

cd vidocq-servlet-chappe-tck-runner
./run-official-tck-servlet6.1.sh

TCK MicroProfile

Les TCK MicroProfile ciblés (Config, Health, Metrics, OpenAPI) seront branchés au fur et à mesure de la livraison des extensions correspondantes. L’architecture des runners suit le même principe : module hors-reactor avec sa propre dépendance ShrinkWrap, lancé via un script run-official-tck-mp-<spec>.sh.

Tests skippés justifiés

Pour les TCK déjà actifs, les exclusions sont documentées dans le TCK.md du sous-projet hôte (par exemple vidocq/TCK.md côté Cassini). Aucun test n’est skippé pour cause d’implémentation incomplète sans entrée correspondante dans BUG.md du module concerné.

Les exclusions standard pour la cible Core Profile / SE-Bootstrap sont :

  • tests dépendant de Jakarta XML Binding ;

  • tests dépendant de Jakarta Server Pages / Faces ;

  • tests dépendant de Jakarta Enterprise Beans ;

  • tests dépendant de Jakarta Authentication / Authorization (hors Core Profile).

Voir vidocq/TCK.md pour la liste complète, les challenges officiels TCK Process 1.4.1 ouverts, et l’historique des sessions de fix.

Bugs ouverts

Les bugs reproductibles découverts pendant les runs TCK sont consignés dans :

  • vidocq/BUG.md — bugs côté orchestrateur Vidocq Runtime ;

  • vidocq/CHAPPE-BUGS.md — bugs Chappe identifiés via TCK Servlet/REST ;

  • vidocq/VAUBAN-BUGS.md — bugs Vauban identifiés via TCK CDI ou Cassini.

Chaque bug suit la convention du workspace : id court, date, repro minimal, hypothèse de cause, statut.

Pour aller plus loin