Nous avons commencé en début de semaine le développement de ToPIA 3. Le but est de se baser sur JPA 2 plutôt que directement sur Hibernate. Ceci devrait nous permettre à terme d'être indépendant de l'implémentation de JPA 2 et donc de pouvoir utiliser autre chose qu'Hibernate. Voici un peu ce que nous avons fait cette semaine. Le module topia-persistence ne dépend plus d'Hibernate, mais dépend de l'API JPA (en provided car chaque implem vient avec son API - pratique !). On ne parle plus de Session Hibernate, mais d'EntityManager. La création d'un EntityManagerFactory passe par une méthode statique (fournie par l'API JPA) qui va chercher dans le classpath un fichier indiquant quel PersistenceProvider il faut utiliser. Le module topia-persistence contient un PersistenceProvider abstrait qui uniformise le comportement quel que soit l'implémentation JPA. Un nouveau module a été créé (topia-persistence-hibernate) qui dépend de topia-persistence et Hibernate (dernière version) et qui fournit un PersistenceProvider en n'implémentant que la partie spécifique à la création d'un EntityManagerFactory Hibernate. Ce PersistenceProvider permet de lire à la fois des fichiers de mapping MonEntite.hbm.xml et MonEntite-orm.xml. Il reste malgré tout un certain nombre de choses qui étaient dans topia-persistence mais qui sont spécifiques à l'implémentation de JPA : - la gestion du schéma (SchemaExport, SchemaUpdate) ; - l'import/export XML ; - la réplication d'entités ; - ... (certainement d'autres qu'on a pas encore bien identifié) Pour gérer ces cas particuliers, j'ai créé une interface (TopiaSpecificUtil - oui je sais le nom est moisi, mais j'ai pas mieux) qui regroupe les méthodes que le TopiaContext ne peut accomplir sans une implémentation spécifique. Lors de la création du PersistenceProvider de l'implémentation choisie, une instance spécifique est créée et injectée au TopiaContext qui pourra ensuite l'utiliser pour les méthodes non JPA. (NB: La gestion du schéma a été migrée dans le module hibernate, mais pas encore l'import/export XML et la réplication d'entités) Le module topia-persistence fournissait aussi un ConnectionProvider qui corrige celui de base d'Hibernate. Étant donné que c'est spécifique Hibernate, ça a été tout naturellement déplacé dans le module topia-persistence-hibernate. Au niveau de la génération des mappings XML, Tony s'arrache bien les cheveux : beaucoup de choses que nous définissions auparavant dans la génération des .hbm.xml n'existe pour les mappings -orm.xml. Nous ne savons pas encore si ces limitations vont être bloquantes. Pour rajouter un peu de peine à la réécriture du générateur, la XSD impose un ordre entre les informations d'une entité (tous les one-to-one, PUIS tous les one-to-many PUIS ... - pratique !). D'autre part, comme 90% des gens utilisent les annotations, 90% des docs qu'on trouve ne parlent même pas des mappings XML : pratique ! (Tony je te laisse compléter si tu veux) Comme nous avons rendu topia-persistence indépendant d'une implémentation JPA, les tests présents dans ce module et nécessitant Hibernate ne peuvent plus s'exécuter depuis ce module (dépendance cyclique). Nous avons donc créé un module topia-persistence-tck (pour Test Compatibility Kit) qui dépend de topia-persistence et qui contient des tests en src/test (non dépendant d'une implem) et des TestSuite en src/main. Dans le module topia-persistence-hibernate, nous avons une dépendance en scope test vers le module topia-persistence-tck et nous surchargeons les TestSuite, ce qui fait que les mêmes tests pourront être partagés entre les différents modules topia-persistence-(hibernate|openjpa|...) À l'heure actuelle, une grande majorité des tests passent en utilisant les mappings .hbm.xml, nous ne savons pas encore ce que ça donnera avec les mappings -orm.xml. Personnellement, je pense que ça va le faire (naturellement optimiste ?) je suis ""juste"" inquiet sur la propagation des évènements (je vais faire un mail dédié). Tony est moins confiant, c'est surement dû au fait que c'est lui qui s'occupe des mappings ORM... Arnaud