pom

[Ghaith-kh]

Audit & Optimisation Multi-Module Maven — lcl-shared-models

Contexte

Librairie partagée de modèles entre microservices LCL (contexte banque, PCI-DSS/RGPD).
Structure actuelle (Maven multi-module) :

• common-pay-models-lib (parent aggregator)
  • lcl-shared-models-core
  • lcl-shared-models-types
  • lcl-shared-models-validation
• ADR/, BREAKING_CHANGES.md, CHECKLIST.md, CONTRIBUTING.md, DEPENDENCIES.md, MIGRATION.md
• CI : .gitlab-ci.yml (déploiement Nexus, scan JFrog XRAY, SonarQube)

Branche courante : refactor/optimize-sh...

Objectif

Audit complet et optimisation des pom.xml (parent + 3 modules) selon les bonnes pratiques Maven pour une librairie partagée consommée par plusieurs microservices Spring Boot.

Périmètre de l'audit

1. POM parent (common-pay-models-lib/pom.xml)

• Vérifier <packaging>pom</packaging> et liste <modules>
• <dependencyManagement> : toutes les versions centralisées ici, aucune version dans les modules enfants
• <pluginManagement> : versions des plugins figées (maven-compiler, surefire, failsafe, jar, source, javadoc, enforcer, versions, sonar, jacoco)
• Properties : java.version, maven.compiler.release, encodages, versions BOMs (Spring Boot, Jackson, Hibernate Validator)
• Import BOM Spring Boot via <scope>import</scope> + <type>pom</type> dans dependencyManagement
• Profils : release, ci, nexus-deploy
• <distributionManagement> Nexus correctement configuré
• maven-enforcer-plugin : requireMavenVersion, requireJavaVersion, dependencyConvergence, bannedDependencies

2. Modules enfants

Pour chaque module (core, types, validation) :

• <parent> bien référencé avec <relativePath>../pom.xml</relativePath>
• Aucune redéclaration de version (tout vient du parent)
• Dépendances minimales et justifiées (principe "shared contracts = pure value objects")
• Vérifier qu'il n'y a pas de dépendances transitives non désirées (Spring Boot starters, JPA, etc.) — c'est une lib de contracts, pas un monolithe distribué
• <scope>provided</scope> pour Lombok / annotations processors
• <scope>test</scope> strictement isolé

3. Cohérence inter-modules

• Ordre des modules dans le parent respecte les dépendances (types → core → validation)
• Pas de dépendance circulaire
• types ne dépend de rien d'autre que JDK + Jakarta Validation API (si nécessaire)
• core peut dépendre de types
• validation peut dépendre de core et types
• Vérifier que validation n'expose pas Hibernate Validator en compile scope (préférer Jakarta Validation API + impl en provided)

4. Bonnes pratiques librairie partagée

• Pas de spring-boot-starter-* en compile (sinon distributed monolith)
• Pas d'annotations JPA (@Entity, @Table)
• Pas de Spring annotations (@Component, @Service)
• Jackson annotations OK si nécessaire (en provided idéalement)
• Lombok en provided + annotation processor
• MapStruct si présent : processor + runtime correctement séparés
• Génération sources + javadoc + tests jars activée pour publication Nexus
• maven-source-plugin et maven-javadoc-plugin attachés au goal verify

5. Qualité & sécurité

• jacoco-maven-plugin configuré (seuils de couverture si applicable)
• sonar-maven-plugin properties (sonar.projectKey, sonar.coverage.jacoco.xmlReportPaths)
• versions-maven-plugin pour détecter dépendances obsolètes
• Pas de CVE connues sur les versions déclarées (cf. contexte JFrog XRAY)
• Versions Spring Boot / Jackson alignées avec les microservices consommateurs (3.5.x)

6. CI/CD

• Lire .gitlab-ci.yml et vérifier cohérence avec les profils Maven
• Tags Git → release Nexus
• Snapshots branches feature → snapshots Nexus

Livrables attendus

1. Rapport d'audit structuré par module avec :

   • ✅ Points conformes
   • ⚠️ Améliorations recommandées (avec justification)
   • ❌ Anti-patterns détectés (avec impact)

2. POMs refactorisés proposés en diff unifié (un bloc par fichier modifié)

3. ADR (Architecture Decision Record) résumant les choix structurants — à placer dans ADR/ selon le format déjà utilisé dans le projet

4. Mise à jour de BREAKING_CHANGES.md si la refacto introduit des changements incompatibles pour les microservices consommateurs (mssepamd, lcl-fraudempa-04781, lcl-virinst-04689-vsepai, etc.)

5. Checklist de validation post-refacto (build clean, install, deploy snapshot, consommation par un MS pilote)

Contraintes

• Java 21 (cible courante des MS LCL)
• Spring Boot 3.5.x côté consommateurs
• Compatibilité Nexus + JFrog XRAY (scan CVE bloquant)
• Conventions de nommage existantes à préserver
• Aucun changement de groupId / artifactId sans flag explicite (impact downstream)

Format de sortie

• Réponse en français
• Code en blocs ```xml fenced
• Diffs en blocs ```diff fenced
• Pas de paraphrase inutile, droit au but
• Citer les fichiers par chemin relatif

Démarrage

Commence par :

1. Lire le parent pom.xml + les 3 POMs enfants
2. Lire .gitlab-ci.yml, DEPENDENCIES.md, CONTRIBUTING.md
3. Établir une cartographie des dépendances actuelles (table)
4. Puis seulement proposer le plan d'action en 3-5 étapes avant de toucher au code