ok, la liste adagio doit maintenant fonctionner.

je réponds dans le texte

Le 30 novembre 2013 13:13, Tony Chemit <chemit@codelutin.com> a écrit :
Hello,

J'écris encore sur cette liste, car je ne suis pas sûr que ça marche adagio-devel (il faudrait ;)).

Il faut qu'on fasse un nettoyage dans les configurations adagio.

Par exemple pour la configuration hibernate, on a :

o src/main/resources/hibernate.cfg non utilisé par spring

=> ce fichier est nécessaire pour liquibase. Il est généré automatiquement par Maven/Ant  et mis ici car liquibase a un bug : il n'est pas capable d'aller chercher ailleurs le fichier... (par exemple dans le target/generated-sources/java)
 
o target/generated-sources/java/un applicationContext-entities.xml

La séparation en plusieurs hibernate est réalisé par AndroMDA. A l'origine, le fichier était "applicationContext.xml", mais je l'ai renommer pour mieux cerner son utilisation.
Le découpage en plusieurs fichiers est une bonen pratique Spring. cela permet par exemple dans les TU de ne pas charger inutilement la couche service.
 

Quel est l'intérêt ?

Il faut autant que possible limiter les fichiers de configuration.
Le choix a été fait d'utiliser spring donc on reste sur spring et on évite la dispersion.

Le jour où quelqu'un aura besoin d'une configuration hibernate en standalone, on en reparlera mais ça n'arrivera pas.

Benoit, je suis bien tenté de supprimer ce fichier.

Un autre point qui ne va pas trop, je vois que des classes sont dupliquées entre les deux module core et core-allegro (typiquement
fr.ifremer.adagio.core.dao.technical.ehcache.EhCacheManagerFactoryBean)


A quoi cela sert-il ? Mieux vaudrait avoir un module commun (core-shared) où on l'on met tout ce qui est commun.

Oui, je voulais faire cela au début.
Pas sûr que le shared fonctionne, à cause des dépendances vers le code généré : le module risque de ne pas compiler.
Nous avions parlé (au début de tutti) d'une copie sous SVN, avec un attribut particulier. Comme je n'ai pas SVN en ligne de commande, je n'avais pas réussi à le faire...
  

En terme de convergence, si on continue à différencer des classes de configuration qui sont les même, ça n'a pas de sens AMHA.

Là encore, le jour où l'on voudra utiliser autre chose dans une des deux implantations, on se posera alors la question de surcharger, mais pas avant.

Désolé d'insister sur ce point, mais il ne faut pas anticiper des besoins qui n'existent pas et qui ne font que compléxifier le systeme (déjà bien compliqué).

Benoit, qu'en penses-tu ? (d'avoir un module au dessus).

Je suis ok si on arrive a simuler une duplication via SVN...
 

Je veux bien te filer un coup de main dans ce sens la semaine prochaine.

tony.

--
Tony Chemit
--------------------
tél: +33 (0) 2 40 50 29 28
http://www.codelutin.com
email: chemit@codelutin.com
twitter: https://twitter.com/tchemit
_______________________________________________
Tutti-devel mailing list
Tutti-devel@list.forge.codelutin.com
http://list.forge.codelutin.com/cgi-bin/mailman/listinfo/tutti-devel