| [ATL] using generated ecore files for GMF [message #40836] |
Wed, 23 May 2007 08:23  |
Eclipse User |
|
|
|
Originally posted by: r.c.ladan.tue.nl
Hi,
I'm using ATL (2007/02/16 bundle download) to generate ecore files for
GMF 1.0 (see http://www.eclipse.org/gmf). It turns out that the
generated ecore files have the following issues:
* two root packages (model + PrimitiveTypes) confuses GMF, but this can
be worked around by moving the data type declarations into the model
package. This looks like a design mismatch to me.
* nsURI == null, solvable by filling in a random value.
* instanceClassName == null for all dataTypes, solvable by setting the
instanceClassNames to the Java equivalent of their Ecore counterparts.
Solving these issues as above allows the generated ecore file to be used
as input for a genmodel file, which in turn can be used to generate
skeleton Java code.
See also the thread "code generation for model/edit code fails?" on
eclipse.modeling.gmf
Regards,
Rene
|
|
|
| Re: [ATL] using generated ecore files for GMF [message #40930 is a reply to message #40836] |
Wed, 23 May 2007 12:50  |
 Frédéric Jouault
Messages: 572
Registered: July 2009 |
Senior Member |
|
|
Hi Rene,
> I'm using ATL (2007/02/16 bundle download) to generate ecore files for
> GMF 1.0 (see http://www.eclipse.org/gmf). It turns out that the
> generated ecore files have the following issues:
>
> * two root packages (model + PrimitiveTypes) confuses GMF, but this can
> be worked around by moving the data type declarations into the model
> package. This looks like a design mismatch to me.
> * nsURI == null, solvable by filling in a random value.
> * instanceClassName == null for all dataTypes, solvable by setting the
> instanceClassNames to the Java equivalent of their Ecore counterparts.
>
> Solving these issues as above allows the generated ecore file to be used
> as input for a genmodel file, which in turn can be used to generate
> skeleton Java code.
>
> See also the thread "code generation for model/edit code fails?" on
> eclipse.modeling.gmf
Thank you for your feedback.
We are already aware of this issue, which is documented in the KM3 FAQ
on the Eclipse wiki:
http://wiki.eclipse.org/index.php/KM3#Why_genmodel_gives_me_ errors_when_I_use_Ecore_model_got_from_KM3-to-Ecore_transfor mation_.3F
Note that you can already set nsURI and nsPrefix to a given value by
doing something like:
-- @nsURI http://myURI
-- @nsPrefix myPrefix
package MyPackage {}
However, your KM3 metamodel now contains XMI-related information. Doing
a similar thing for instanceClassName would make it contain
Java-specific information. Going further would make it contain
EMF-specific information. This is not very clean for a "Kernel"
MetaMetaModel ;-).
As the FAQ entry states, the next version of KM3 will provide a clean
solution for this. And of course, it will use model weaving (cf., AMW:
http://www.eclipse.org/gmt/amw/) to annotate the KM3 metamodels without
modifying them in any way, so that they remain independent of any
implementation technology.
Regards,
Frédéric Jouault
|
|
|
| Re: [ATL] using generated ecore files for GMF [message #41422 is a reply to message #40930] |
Thu, 24 May 2007 14:21 |
| Eclipse User |
|
|
|
Originally posted by: r.c.ladan.tue.nl
Frédéric Jouault wrote:
> Hi Rene,
>
>
> > I'm using ATL (2007/02/16 bundle download) to generate ecore files for
> > GMF 1.0 (see http://www.eclipse.org/gmf). It turns out that the
> > generated ecore files have the following issues:
> >
> > * two root packages (model + PrimitiveTypes) confuses GMF, but this can
> > be worked around by moving the data type declarations into the model
> > package. This looks like a design mismatch to me.
> > * nsURI == null, solvable by filling in a random value.
> > * instanceClassName == null for all dataTypes, solvable by setting the
> > instanceClassNames to the Java equivalent of their Ecore counterparts.
> >
[...]
> We are already aware of this issue, which is documented in the KM3 FAQ
> on the Eclipse wiki:
>
> http://wiki.eclipse.org/index.php/KM3#Why_genmodel_gives_me_ errors_when_I_use_Ecore_model_got_from_KM3-to-Ecore_transfor mation_.3F
>
>
> Note that you can already set nsURI and nsPrefix to a given value by
> doing something like:
>
> -- @nsURI http://myURI
> -- @nsPrefix myPrefix
> package MyPackage {}
>
The nsURI part indeed solves the need to add it manually to the ecore
file. But the namespace markers seem to confuse the ATL engine: when I
load an input ecore file which references an ecore file with
nsURI/nsPrefix set, the engine cannot find the namespace anymore.
So I guess I'll have to maintain two versions of each km3 file for now
(one for ATL, one for GMF).
Regards,
Rene
|
|
|
Powered by
FUDForum. Page generated in 0.03880 seconds
] 
Search
Help
Register
Login
Home
