Bonjour Didier,

En octobre dernier, je t'écrivais au sujet d'un problème relié aux
références circulaires entre .ecore. Depuis, j'ai simplement fusionner les
fichiers .ecore en un seul fichier pour contourner le problème. Cependant,
aujourd'hui j'ai tenté de retourner aux fichiers .ecore originaux et j'ai
du nouveau sur le problème.

À partir d'un exemple simple (voir attachement), j'ai tenté de charger un
modèle dont le métamodèle est défini à l'aide de deux fichiers .ecore
ayant des références circulaire entre eux. Comme tu l'avais souligné en
octobre dernier, Kermeta se retrouve avec des doublons de définitions
lorsque les fichiers .ecore sont parfois référencés par des nsURI et
parfois référencés par des chemins relatifs. J'ai donc tenté d'utiliser
seulement les chemins relatifs.

Observation 1
Lorsque je clique sur "Check this file" plusieurs fois, Kermeta signale
que le metamodèle contient des erreurs. Ce n'est pas le cas lorsqu'il n'y
a pas de référence circulaire entre les deux fichiers .ecore.

Observation 2
Lorsque je tente de "Generate Kermeta Source (=>kmt)", Kermeta signale que
le metamodèle contient des erreurs. Ce n'est pas le cas lorsqu'il n'y a
pas de référence circulaire entre les deux fichiers .ecore.

Observation 3
Pour les deux premières observations, les nsURI et le "EMF package
registry" n'étaient pas utilisés. Par contre, il me semble inévitable
d'utiliser le "EMF package registry" afin de faire le lien entre le
modèle(.xmi) et le métamodel(.ecore). J'assume que ta suggestion de "tout
passer en référence fichier" s'appliquait aux références d'un fichier
kermeta à un fichier .ecore et aux références d'un fichier .ecore à un
autre fichier .ecore.

Conclusion
Certe, il y avait un problème avec les doublons de définitions. Cependant,
suite à la résolution de ce problème Kermeta ne peut toujours pas charger
un modèle dont le métamodèle est définit dans plusieurs fichiers ayant des
références circulaire entre eux. Je crois qu'il y a un bug. J'apprécierais
beaucoup avoir ton point de vue sur le problème.

Merci beaucoup,
Stéphane

Ps: J'ai créé un "post" sur la mailing list, on peut y continuer la
discussion. Je crois qu'il m'était impossible de t'envoyer un attachement
à l'aide de la mailing list.

> 2/ pour le second, le problème viens principalement du fait que ton
> ensemble de ecore n'est pas cohérent, tu mélange des références vers des
> EPackage issus de fichier. et des EPackage issus de la mémoire (registry
> d'eclipse) via les nsURI,
>
> Dans les fait, quand tu charge l'un de tes métamodèle, tu te retrouve en
> mémoire avec des doublons de tes définitions (et comme elles sont issues
> de ecore, elle ne sont pas marquées comme "aspect" et donc ne peuvent être
> fusionnées...) En effet, EMF ne propose pas de mécanisme sûr pour dire que
> 2 instances chargées par des chemins différents (de EPackage/EClass, etc)
> sont en fait similaire.
>
> Le mieux c'est de clarifier le métamodèle si tu en as le controle et de
> n'utiliser qu'un seul type de pointeur. Soit en utilisant les nsURi, soit
> en utilisant les accés relatifs à un fichier voisin. (cela se voie en
> ouvrant le fichier ecore en mode texte.) et coté kermeta utiliser le même
> système.
>
> Vu le coté circulaire,
> si tu veux le plus simple c'est de tout passer en référence fichier
> (utilise platform:/lookup pour chercher soit dans les projets, soit dans
> les plugin)
> un peu plus compliqué (mais je pense réalisable), tout passer en nsURI,
> mais il risque d'être nécessaire de générer le code java et de le déployer
> dans ton eclipse pour qu'il l'enregistre correctement au démarrage
> d'éclipse... (c'est moins souple si tu doit encore modifier les ecore :-(
> )