hello Pierrick has found where the meta models and the meta meta models are loaded. They are in the Class System. To get the meta models, do: System reference metamodel. To get the meta meta modles do: System reference metaMetamodel sara

Hi! I have a question concerning the structure of a MooseModel. Imagine that we have a project with three Namespaces: Namespace A, NamespaceB, NamespaceC. In my project, NamespaceA contains NamespaceB and NamespaceC. Then, I import the project in Moose and I get a MooseModel with my three namespaces. When I inspect NamespaceB and NamespaceC, I can see (thanks to the attribute 'belongsTo') that they both belong to NamespaceA Nevertheless, when I inspect NamespaceA, I realise that attribute 'namespaces' is an empty OrderedCollection. Is it normal? Because I think that 'namespaces ' should contain NamespaceB and NamespaceC, isn't it? thanks Sara

I can understand that we have only one MMModel but I do not understand why I cannot have different MModel. It seems completely hopeless then that we continue to work on importing EMF metamodels in Moose. Should I really say to sara and pierrick to stop? Still I do not understand why I could not have different models for example FAMIX and Mushroom. I do not need model import right now. I do not really understand what you mean. For now I do not need a different namespace. The point for now is that we just need a kind of repository where we could get the different metaModels: MetaModelRepository default modelNamed: #Famix MetaModelRepository default modelNamed: #Mushrooms So then there is no point to load MModel in Moose then. Stef

On 18 Jul 2007, at 11:17 , Stéphane Ducasse wrote: To answer that, we have to distinguish between Meta and Moose. You can load multiple Metamodels in Meta, but alas, not in Moose. Let me elaborate that a bit more: -------- Meta Meta.System is a container for one set of Model, MModel and MMModel. There can be as many System instances as you want, and they may share all the same MMModel. Similar to a singelton, one selected system is always the current reference system System reference which can be changed using a context oriented scheme mySystem scopeWhile: [ .... ] which will make mySystem the reference system within the context of that block. Let's assume that you want to load two MModels, Famix and Mushroom, sharing the same MMModel | famix mushroom | famix := System withEMOF. mushroom := famix withSameMetaMetamodel. famix scopeWhile: [ "...load Famix metamodel here..." ]. mushroom scopeWhile: [ "...load Mushroom metamodel here..." ]. and then you can access for example Mushroom's elements either direct mushroom metamodel elements or using the context oriented way mushroom scopeWhile: [ System reference metamodel elements ] the you can do the same for models, having multiple mushroom models | mario luigi | mario := mushroom withSameMetamodel. luigi := mushroom withSameMetamodel. mario scopeWhile: [ "... load a Mushroom model ..." ]. luigi scopeWhile: [ "... load another Mushroom model ...' ]. and again you can access elements direct or via context mario elements. mario scopeWhile: [ System reference model elements ]. --------- Moose Alas, Moose does not use multiple System instances for multiple Models or MModels. Moose does everything using the default reference system. Hence all metamodels that you load into Moose are merged into M2 layer of the default reference system! In other words, you can not load Metamodels into Moose, you can only extend Moose's default Metamodel with your custom elements. By the way, for the models, Moose doesn't even use the default reference system, but manages its "models" somewhere outside in custom data containers not related to Meta. cheers, AA

I have exactly the same effect with any namespace I import (for namespaces imported as side-info as well as namespace which I am importing). It would be nicer if they would actually be nested since one of the clustering algorithms uses the recursiveClasses (which currently gives back exactly the same as classes), and which would automatically be nested in the cluster browser... Reproducing just comes down to loading whatever namespace which has subnamespaces (SCG?) and inspecting it :) Toon On (18/07/07 09:15), Adrian Kuhn wrote: