Vidocq Documentation

Vauban est en 0.1.0-SNAPSHOT. Une migration réelle d’application est prématurée tant que la couverture TCK n’est pas consolidée (voir état TCK). Cette page documente les correspondances de modèle et les pièges connus pour préparer la transition.

Vauban implémente le profil CDI 4.1 Lite. Migrer suppose donc d’abandonner les fonctionnalités du profil Full quand elles sont utilisées (portable extensions runtime, @ConversationScoped, passivation, EL applicatif).

Depuis Quarkus ArC

ArC partage la philosophie build-time de Vauban. Le portage est conceptuellement direct ; les écarts sont surtout outillage.

ArC Vauban Note

Build-time CDI complet

Build-time CDI complet

Modèle identique. Aucun changement de paradigme côté code applicatif.

Génération bytecode via Gizmo

Génération bytecode via Class-File API (JEP 484)

Pas d’ASM. La sortie est compatible avec n’importe quel JVM 25+.

@io.quarkus.arc.Unremovable

Pas d’équivalent direct

Vauban élimine actuellement uniquement les beans non référencés. // TODO@user: confirmer si une annotation similaire est planifiée.

@io.quarkus.arc.profile.IfBuildProfile

Pas d’équivalent

Le profilage build-time relève de la couche Vidocq Runtime.

Quarkus Dev Mode

vauban-junit + cycle Maven standard

Vauban n’a pas de Dev Mode dédié.

@Startup

@Observes @Initialized(ApplicationScoped.class)

Pattern CDI standard.

Depuis Weld

Weld implémente le profil Full ; certaines fonctionnalités utilisées par les applications historiques n’ont pas d’équivalent en Lite.

Différences clés :

  • Pas d'`AnnotatedType` lookup runtime — Vauban résout tout à la compilation. Le code qui appelle BeanManager.createAnnotatedType(Class) doit être réécrit en Build Compatible Extension.

  • Pas de BeforeBeanDiscovery / AfterBeanDiscovery runtime — remplacé par les phases BCE @Discovery / @Enhancement / @Registration / @Synthesis / @Validation.

  • Pas de portable extensions — l’interface Extension n’est pas chargée via ServiceLoader au runtime. Migrer chaque extension vers une BCE compile-time.

  • Pas de @ConversationScoped — refactorer en @SessionScoped (// TODO@user: confirmer support) ou en mécanisme applicatif explicite.

Tableau exhaustif Weld → Vauban des features supportées / non supportées. // TODO@user

Depuis OpenWebBeans

OpenWebBeans est très proche de Weld dans ses APIs. Le tableau Weld s’applique en grande partie. Les particularités OWB (résolution de bean différée, BeanArchive custom) ne sont pas supportées : Vauban n’a qu’un seul mode de découverte, statique.

Pièges CDI 4.1 Lite

Spécificités du profil Lite à connaître avant migration :

  • @Decorator — supporté en Lite, à valider sur votre code. // TODO@user: confirmer la couverture exacte.

  • @Specializes — non supporté. Refactorer en composition ou en @Alternative priorisée.

  • @Alternative + @Priority — supporté ; vérifier les priorités existantes.

  • Producer methods avec @Disposes — supportés.

  • Champ @Inject sur scope normal — résout bien le client proxy (cf. correctif VAU-INJ-001 dans BUG.md).

  • InjectionPoint metadata — supporté.

Stratégie recommandée

  1. Faire tourner le code existant sous Vauban dans une branche dédiée.

  2. Lancer vauban:analyze pour détecter les split packages et exports JPMS manquants.

  3. Exécuter vauban-test-suite adapté au domaine applicatif.

  4. Activer la TCK CDI 4.1 Lite sur l’application elle-même via vauban-junit.

  5. Itérer sur les BCE pour remplacer les portable extensions.

  6. Tester en GraalVM native-image pour valider l’absence de réflexion résiduelle.

Pour aller plus loin