Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » No model interfaces generated. Why?
No model interfaces generated. Why? [message #518286] Wed, 03 March 2010 16:48 Go to next message
Eclipse UserFriend
Originally posted by: m_lehmeier.gmx.de

Hello.
I have a problem.
I created a test project with an ecore model. It is a fairly simple
model, just for testing purposes.

Then I created a genmodel out of it and used it to generate model code.
I was then greeted by many java error messages. As it turns out, it
didn't generate most interfaces, just the implementation of the classes.
The classes therefore implement interfaces that don't exist.
The only interface that got created was of the only enum I used in the
model.
I tried with an unmodified generated genmodel: Same problem.

Then I switch workspace to an old project with a much more complicated
ecore model. There it would generate interfaces just fine. I'm not aware
of any differences to my current project.

Can anybody tell me under which circumstances it can happen that I don't
get any interfaces?

Thanks!

Because it is so small, this is the whole ecore file I used:

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="SwingTest"
nsURI="http://lm.swingtest.de" nsPrefix="swingtest">
<eClassifiers xsi:type="ecore:EClass" name="Panel"
instanceClassName="Panel" eSuperTypes="#//Component">
<eStructuralFeatures xsi:type="ecore:EReference" name="childComponents"
upperBound="-1"
eType="#//Component" containment="true"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="orientation"
lowerBound="1"
eType="#//Orientation" defaultValueLiteral="ROWS"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="maxChildren"
lowerBound="1"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt"
defaultValueLiteral="3"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Frame"
instanceClassName="Frame">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="width"
lowerBound="1" eType="ecore:EDataType
http://www.eclipse.org/emf/2002/Ecore#//EInt"
defaultValueLiteral="300"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="height"
lowerBound="1"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt"
defaultValueLiteral="300"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
lowerBound="1" eType="ecore:EDataType
http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EEnum" name="Orientation"
instanceClassName="Orientation">
<eLiterals name="COLUMNS" literal="Columns"/>
<eLiterals name="ROWS" value="1" literal="Rows"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Component"
instanceClassName="Component"
abstract="true"/>
<eClassifiers xsi:type="ecore:EClass" name="Button"
instanceClassName="Button" eSuperTypes="#//Component">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
lowerBound="1" eType="ecore:EDataType
http://www.eclipse.org/emf/2002/Ecore#//EString"
defaultValueLiteral="A Button"/>
</eClassifiers>
</ecore:EPackage>

--
Lehmeier Michael
Re: No model interfaces generated. Why? [message #518287 is a reply to message #518286] Wed, 03 March 2010 12:04 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33142
Registered: July 2009
Senior Member
Michael,

Comments below.

Michael Lehmeier wrote:
> Hello.
> I have a problem.
> I created a test project with an ecore model. It is a fairly simple
> model, just for testing purposes.
>
> Then I created a genmodel out of it and used it to generate model code.
> I was then greeted by many java error messages. As it turns out, it
> didn't generate most interfaces, just the implementation of the classes.
> The classes therefore implement interfaces that don't exist.
> The only interface that got created was of the only enum I used in the
> model.
> I tried with an unmodified generated genmodel: Same problem.
>
> Then I switch workspace to an old project with a much more complicated
> ecore model. There it would generate interfaces just fine. I'm not aware
> of any differences to my current project.
>
> Can anybody tell me under which circumstances it can happen that I don't
> get any interfaces?
>
> Thanks!
>
> Because it is so small, this is the whole ecore file I used:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="SwingTest"
> nsURI="http://lm.swingtest.de" nsPrefix="swingtest">
> <eClassifiers xsi:type="ecore:EClass" name="Panel"
> instanceClassName="Panel"
See how you've defined an instanceClassName. That makes this EClass act
as a wrapper for the specified pre-existing instance class named Panel.
> eSuperTypes="#//Component">
> <eStructuralFeatures xsi:type="ecore:EReference" name="childComponents"
> upperBound="-1"
> eType="#//Component" containment="true"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="orientation"
> lowerBound="1"
> eType="#//Orientation" defaultValueLiteral="ROWS"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="maxChildren"
> lowerBound="1"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt"
> defaultValueLiteral="3"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Frame"
> instanceClassName="Frame">
>
Here you've done that again.
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="width"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EInt"
> defaultValueLiteral="300"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="height"
> lowerBound="1"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt"
> defaultValueLiteral="300"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EEnum" name="Orientation"
> instanceClassName="Orientation">
> <eLiterals name="COLUMNS" literal="Columns"/>
> <eLiterals name="ROWS" value="1" literal="Rows"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Component"
> instanceClassName="Component"
> abstract="true"/>
> <eClassifiers xsi:type="ecore:EClass" name="Button"
> instanceClassName="Button" eSuperTypes="#//Component">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EString"
> defaultValueLiteral="A Button"/>
> </eClassifiers>
> </ecore:EPackage>
>
Only set an instance class name on any EClassifier to something that
really already exists in Java.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: No model interfaces generated. Why? [message #518306 is a reply to message #518287] Wed, 03 March 2010 12:44 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: m_lehmeier.gmx.de

On 2010-03-03, Ed Merks <Ed.Merks@gmail.com> wrote:
> Michael,
>
> Comments below.
>
> Only set an instance class name on any EClassifier to something that
> really already exists in Java.

Thank you, I didn't know that.
I didn't set the instance class name in my old project because I didn't
use the generic model editor at that time and only that one shows this
option.
The generic model editor insist on filling out that field at least with
java.lang.Object. Bug?

Anyway, as nice as it sounded, this didn't solve my problem.
I still don't get any interfaces besides the enum.

My model now looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="SwingTest"
nsURI="http://lm.swingtest.de" nsPrefix="swingtest">
<eClassifiers xsi:type="ecore:EClass" name="Panel"
instanceTypeName="Panel" eSuperTypes="#//Component">
<eStructuralFeatures xsi:type="ecore:EReference" name="childComponents"
upperBound="-1"
eType="#//Component" containment="true"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="orientation"
lowerBound="1"
eType="#//Orientation" defaultValueLiteral="ROWS"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="maxChildren"
lowerBound="1"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt"
defaultValueLiteral="3"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Frame"
instanceTypeName="Frame">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="width"
lowerBound="1" eType="ecore:EDataType
http://www.eclipse.org/emf/2002/Ecore#//EInt"
defaultValueLiteral="300"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="height"
lowerBound="1"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt"
defaultValueLiteral="300"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
lowerBound="1" eType="ecore:EDataType
http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EEnum" name="Orientation"
instanceTypeName="Orientation">
<eLiterals name="COLUMNS" literal="Columns"/>
<eLiterals name="ROWS" value="1" literal="Rows"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Component"
instanceTypeName="Component"
abstract="true"/>
<eClassifiers xsi:type="ecore:EClass" name="Button"
instanceTypeName="Button" eSuperTypes="#//Component">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
lowerBound="1" eType="ecore:EDataType
http://www.eclipse.org/emf/2002/Ecore#//EString"
defaultValueLiteral="A Button"/>
</eClassifiers>
</ecore:EPackage>

--
Lehmeier Michael
Re: No model interfaces generated. Why? [message #518315 is a reply to message #518306] Wed, 03 March 2010 17:50 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33142
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------030705010007040404060208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Michael,

I snipped your example, created a new project with it, and it generated
fine, so can't reproduce a problem. You're sure you aren't still using
the older version? What if you create an additional EClass. Is there
an Impl but no interface for it?

Which editor insists of setting it to java.lang.Object? The Sample
Ecore Editor doesn't do that for me.

Cheers,
Ed


Michael Lehmeier wrote:
> On 2010-03-03, Ed Merks <Ed.Merks@gmail.com> wrote:
>
>> Michael,
>>
>> Comments below.
>>
>> Only set an instance class name on any EClassifier to something that
>> really already exists in Java.
>>
>
> Thank you, I didn't know that.
> I didn't set the instance class name in my old project because I didn't
> use the generic model editor at that time and only that one shows this
> option.
> The generic model editor insist on filling out that field at least with
> java.lang.Object. Bug?
>
> Anyway, as nice as it sounded, this didn't solve my problem.
> I still don't get any interfaces besides the enum.
>
> My model now looks like this:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="SwingTest"
> nsURI="http://lm.swingtest.de" nsPrefix="swingtest">
> <eClassifiers xsi:type="ecore:EClass" name="Panel"
> instanceTypeName="Panel" eSuperTypes="#//Component">
> <eStructuralFeatures xsi:type="ecore:EReference" name="childComponents"
> upperBound="-1"
> eType="#//Component" containment="true"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="orientation"
> lowerBound="1"
> eType="#//Orientation" defaultValueLiteral="ROWS"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="maxChildren"
> lowerBound="1"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt"
> defaultValueLiteral="3"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Frame"
> instanceTypeName="Frame">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="width"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EInt"
> defaultValueLiteral="300"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="height"
> lowerBound="1"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt"
> defaultValueLiteral="300"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EEnum" name="Orientation"
> instanceTypeName="Orientation">
> <eLiterals name="COLUMNS" literal="Columns"/>
> <eLiterals name="ROWS" value="1" literal="Rows"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Component"
> instanceTypeName="Component"
> abstract="true"/>
> <eClassifiers xsi:type="ecore:EClass" name="Button"
> instanceTypeName="Button" eSuperTypes="#//Component">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EString"
> defaultValueLiteral="A Button"/>
> </eClassifiers>
> </ecore:EPackage>
>
>

--------------030705010007040404060208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Michael,<br>
<br>
I snipped your example, created a new project with it, and it generated
fine, so can't reproduce a problem.&nbsp;&nbsp; You're sure you aren't still
using the older version?&nbsp; What if you create an additional EClass.&nbsp; Is
there an Impl but no interface for it?<br>
<br>
Which editor insists of setting it to java.lang.Object?&nbsp; The Sample
Ecore Editor doesn't do that for me.<br>
<br>
Cheers,<br>
Ed<br>
<br>
<br>
Michael Lehmeier wrote:
<blockquote cite="mid:r4j267-qc8.ln1@daradja.de" type="cite">
<pre wrap="">On 2010-03-03, Ed Merks <a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com">&lt;Ed.Merks@gmail.com&gt;</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Michael,

Comments below.

Only set an instance class name on any EClassifier to something that
really already exists in Java.
</pre>
</blockquote>
<pre wrap=""><!---->
Thank you, I didn't know that.
I didn't set the instance class name in my old project because I didn't
use the generic model editor at that time and only that one shows this
option.
The generic model editor insist on filling out that field at least with
java.lang.Object. Bug?

Anyway, as nice as it sounded, this didn't solve my problem.
I still don't get any interfaces besides the enum.

My model now looks like this:

&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;ecore:EPackage xmi:version="2.0"
xmlns:xmi=<a class="moz-txt-link-rfc2396E" href="http://www.omg.org/XMI">"http://www.omg.org/XMI"</a>
xmlns:xsi=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/XMLSchema-instance">"http://www.w3.org/2001/XMLSchema-instance"</a>
xmlns:ecore=<a class="moz-txt-link-rfc2396E" href="http://www.eclipse.org/emf/2002/Ecore">"http://www.eclipse.org/emf/2002/Ecore"</a> name="SwingTest"
nsURI=<a class="moz-txt-link-rfc2396E" href="http://lm.swingtest.de">"http://lm.swingtest.de"</a> nsPrefix="swingtest"&gt;
&lt;eClassifiers xsi:type="ecore:EClass" name="Panel"
instanceTypeName="Panel" eSuperTypes="#//Component"&gt;
&lt;eStructuralFeatures xsi:type="ecore:EReference" name="childComponents"
upperBound="-1"
eType="#//Component" containment="true"/&gt;
&lt;eStructuralFeatures xsi:type="ecore:EAttribute" name="orientation"
lowerBound="1"
eType="#//Orientation" defaultValueLiteral="ROWS"/&gt;
&lt;eStructuralFeatures xsi:type="ecore:EAttribute" name="maxChildren"
lowerBound="1"
eType="ecore:EDataType <a class="moz-txt-link-freetext" href="http://www.eclipse.org/emf/2002/Ecore#//EInt">http://www.eclipse.org/emf/2002/Ecore#//EInt</a>"
defaultValueLiteral="3"/&gt;
&lt;/eClassifiers&gt;
&lt;eClassifiers xsi:type="ecore:EClass" name="Frame"
instanceTypeName="Frame"&gt;
&lt;eStructuralFeatures xsi:type="ecore:EAttribute" name="width"
lowerBound="1" eType="ecore:EDataType
<a class="moz-txt-link-freetext" href="http://www.eclipse.org/emf/2002/Ecore#//EInt">http://www.eclipse.org/emf/2002/Ecore#//EInt</a>"
defaultValueLiteral="300"/&gt;
&lt;eStructuralFeatures xsi:type="ecore:EAttribute" name="height"
lowerBound="1"
eType="ecore:EDataType <a class="moz-txt-link-freetext" href="http://www.eclipse.org/emf/2002/Ecore#//EInt">http://www.eclipse.org/emf/2002/Ecore#//EInt</a>"
defaultValueLiteral="300"/&gt;
&lt;eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
lowerBound="1" eType="ecore:EDataType
<a class="moz-txt-link-freetext" href="http://www.eclipse.org/emf/2002/Ecore#//EString">http://www.eclipse.org/emf/2002/Ecore#//EString</a>"/&gt;
&lt;/eClassifiers&gt;
&lt;eClassifiers xsi:type="ecore:EEnum" name="Orientation"
instanceTypeName="Orientation"&gt;
&lt;eLiterals name="COLUMNS" literal="Columns"/&gt;
&lt;eLiterals name="ROWS" value="1" literal="Rows"/&gt;
&lt;/eClassifiers&gt;
&lt;eClassifiers xsi:type="ecore:EClass" name="Component"
instanceTypeName="Component"
abstract="true"/&gt;
&lt;eClassifiers xsi:type="ecore:EClass" name="Button"
instanceTypeName="Button" eSuperTypes="#//Component"&gt;
&lt;eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
lowerBound="1" eType="ecore:EDataType
<a class="moz-txt-link-freetext" href="http://www.eclipse.org/emf/2002/Ecore#//EString">http://www.eclipse.org/emf/2002/Ecore#//EString</a>"
defaultValueLiteral="A Button"/&gt;
&lt;/eClassifiers&gt;
&lt;/ecore:EPackage&gt;

</pre>
</blockquote>
</body>
</html>

--------------030705010007040404060208--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: No model interfaces generated. Why? [message #518320 is a reply to message #518315] Wed, 03 March 2010 13:54 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: m_lehmeier.gmx.de

On 2010-03-03, Ed Merks <Ed.Merks@gmail.com> wrote:
>
> Michael,
>
> I snipped your example, created a new project with it, and it
> generated
> fine, so can't reproduce a problem. You're sure you aren't still
> using
> the older version?

Eclipse Modeling Tools
Version: 1.2.2.20100216-1730
Build id: 20100218-1602
I just ran an update, it didn't help.

> What if you create an additional EClass. Is there
> an Impl but no interface for it?

This helped me solve the problem.
Not only do I have to leave the Instance Class Name field empty, but
also the Instance Type Name field.
Now the interfaces are generated. Thank you very much.
But I wonder why you were not able to reproduce the problem.

> Which editor insists of setting it to java.lang.Object? The Sample
> Ecore Editor doesn't do that for me.

I mistyped, I meant the Generic EMF Form Editor
It is much more comfortable since it allows jumping from field to field
with tabs.
IMO the ability of modelling without using the mouse leaves much to be
desired and that editor was a huge step forward.

However, it doesn't seem to be a bug there. The Instance Class Name
defaults to java.lang.Object, but when I save the attribute is not
shown. No problem there. I just filled out fields I shouldn't have.


While the one problem is now solved, I now have an intresting
second one.
I have an enum as an attribute in a class.

The generated code shows this:

public void eSet(int featureID, Object newValue) {
switch (featureID) {
case SwingtestPackage.PANEL__CHILD_COMPONENTS:
getChildComponents().clear();
getChildComponents().addAll((Collection<? extends Component>)newValue);
return;
case SwingtestPackage.PANEL__MAX_CHILDREN:
setMaxChildren((Integer)newValue);
return;
case SwingtestPackage.PANEL__ORIENTATION:
setOrientation(newValue);
return;
}
super.eSet(featureID, newValue);
}

The command setOrientation(newValue) fails because of the missing cast.

Any idea?


<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="swingtest"
nsURI="http://lm.swingtest.de" nsPrefix="swingtest">
<eClassifiers xsi:type="ecore:EClass" name="Panel"
eSuperTypes="#//Component">
<eStructuralFeatures xsi:type="ecore:EReference" name="childComponents"
upperBound="-1"
eType="#//Component" containment="true"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="maxChildren"
lowerBound="1"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt"
defaultValueLiteral="3"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="orientation"
lowerBound="1"
eType="#//Orientation" defaultValueLiteral="ROWS"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Frame">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="width"
lowerBound="1" eType="ecore:EDataType
http://www.eclipse.org/emf/2002/Ecore#//EInt"
defaultValueLiteral="300"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="height"
lowerBound="1"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt"
defaultValueLiteral="300"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
lowerBound="1" eType="ecore:EDataType
http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EEnum" name="Orientation"
instanceTypeName="Orientation">
<eLiterals name="COLUMNS" literal="Columns"/>
<eLiterals name="ROWS" value="1" literal="Rows"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Component" abstract="true"/>
<eClassifiers xsi:type="ecore:EClass" name="Button"
eSuperTypes="#//Component">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
lowerBound="1" eType="ecore:EDataType
http://www.eclipse.org/emf/2002/Ecore#//EString"
defaultValueLiteral="A Button"/>
</eClassifiers>
</ecore:EPackage>

--
Lehmeier Michael
Re: No model interfaces generated. Why? [message #518322 is a reply to message #518320] Wed, 03 March 2010 19:06 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: m_lehmeier.gmx.de

On 2010-03-03, Michael Lehmeier <m_lehmeier@gmx.de> wrote:
>
> While the one problem is now solved, I now have an intresting
> second one.
> I have an enum as an attribute in a class.

Nevermind.
I recreated that enum using the orginal editor and now it works.

It seems to me that EMF is really fragile in its usage to those who
don't know yet most or all of its features.
Well, I have to keep on learning.

--
Lehmeier Michael
Re: No model interfaces generated. Why? [message #518347 is a reply to message #518320] Wed, 03 March 2010 20:51 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33142
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------080507060608080907050807
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Michael,

Comments below.


Michael Lehmeier wrote:
> On 2010-03-03, Ed Merks <Ed.Merks@gmail.com> wrote:
>
>> Michael,
>>
>> I snipped your example, created a new project with it, and it
>> generated
>> fine, so can't reproduce a problem. You're sure you aren't still
>> using
>> the older version?
>>
>
> Eclipse Modeling Tools
> Version: 1.2.2.20100216-1730
> Build id: 20100218-1602
> I just ran an update, it didn't help.
>
>
>> What if you create an additional EClass. Is there
>> an Impl but no interface for it?
>>
>
> This helped me solve the problem.
> Not only do I have to leave the Instance Class Name field empty, but
> also the Instance Type Name field.
>
Is some tool letting you specify both? The latter is former is
essentially derived from the latter.
> Now the interfaces are generated. Thank you very much.
> But I wonder why you were not able to reproduce the problem.
>
>
>> Which editor insists of setting it to java.lang.Object? The Sample
>> Ecore Editor doesn't do that for me.
>>
>
> I mistyped, I meant the Generic EMF Form Editor
> It is much more comfortable since it allows jumping from field to field
> with tabs.
>
I'm not sure what that is.
> IMO the ability of modelling without using the mouse leaves much to be
> desired and that editor was a huge step forward.
>
Yes it would be nice to have time to use EEF to generate nice forms for
EMF. The Ecore Tools editor has nice forms too.
> However, it doesn't seem to be a bug there. The Instance Class Name
> defaults to java.lang.Object, but when I save the attribute is not
> shown. No problem there. I just filled out fields I shouldn't have.
>
When there is an instance type name specified, the instance class name
is the Java erasure of that name, i.e., for
java.util.List<java.lang.Integer> instance type name it would be
java.util.List instance class name. Since no erasure can be computed
for just a name like Foo, java.lang.Object is assumed.

>
> While the one problem is now solved, I now have an intresting
> second one.
> I have an enum as an attribute in a class.
>
> The generated code shows this:
>
> public void eSet(int featureID, Object newValue) {
> switch (featureID) {
> case SwingtestPackage.PANEL__CHILD_COMPONENTS:
> getChildComponents().clear();
> getChildComponents().addAll((Collection<? extends Component>)newValue);
> return;
> case SwingtestPackage.PANEL__MAX_CHILDREN:
> setMaxChildren((Integer)newValue);
> return;
> case SwingtestPackage.PANEL__ORIENTATION:
> setOrientation(newValue);
> return;
> }
> super.eSet(featureID, newValue);
> }
>
> The command setOrientation(newValue) fails because of the missing cast.
>
I couldn't reproduce that either, but that's no doubt related to the
instance type name issue too.
> Any idea?
>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0"
> xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="swingtest"
> nsURI="http://lm.swingtest.de" nsPrefix="swingtest">
> <eClassifiers xsi:type="ecore:EClass" name="Panel"
> eSuperTypes="#//Component">
> <eStructuralFeatures xsi:type="ecore:EReference" name="childComponents"
> upperBound="-1"
> eType="#//Component" containment="true"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="maxChildren"
> lowerBound="1"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt"
> defaultValueLiteral="3"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="orientation"
> lowerBound="1"
> eType="#//Orientation" defaultValueLiteral="ROWS"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Frame">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="width"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EInt"
> defaultValueLiteral="300"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="height"
> lowerBound="1"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt"
> defaultValueLiteral="300"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EEnum" name="Orientation"
> instanceTypeName="Orientation">
> <eLiterals name="COLUMNS" literal="Columns"/>
> <eLiterals name="ROWS" value="1" literal="Rows"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Component" abstract="true"/>
> <eClassifiers xsi:type="ecore:EClass" name="Button"
> eSuperTypes="#//Component">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
> lowerBound="1" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EString"
> defaultValueLiteral="A Button"/>
> </eClassifiers>
> </ecore:EPackage>
>
>

--------------080507060608080907050807
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Michael,<br>
<br>
Comments below.<br>
<br>
<br>
Michael Lehmeier wrote:
<blockquote cite="mid:8hn267-g2a.ln1@daradja.de" type="cite">
<pre wrap="">On 2010-03-03, Ed Merks <a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com">&lt;Ed.Merks@gmail.com&gt;</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Michael,

I snipped your example, created a new project with it, and it
generated
fine, so can't reproduce a problem. You're sure you aren't still
using
the older version?
</pre>
</blockquote>
<pre wrap=""><!---->
Eclipse Modeling Tools
Version: 1.2.2.20100216-1730
Build id: 20100218-1602
I just ran an update, it didn't help.

</pre>
<blockquote type="cite">
<pre wrap="">What if you create an additional EClass. Is there
an Impl but no interface for it?
</pre>
</blockquote>
<pre wrap=""><!---->
This helped me solve the problem.
Not only do I have to leave the Instance Class Name field empty, but
also the Instance Type Name field.
</pre>
</blockquote>
Is some tool letting you specify both?&nbsp; The latter is former is
essentially derived from the latter.<br>
<blockquote cite="mid:8hn267-g2a.ln1@daradja.de" type="cite">
<pre wrap="">Now the interfaces are generated. Thank you very much.
But I wonder why you were not able to reproduce the problem.

</pre>
<blockquote type="cite">
<pre wrap="">Which editor insists of setting it to java.lang.Object? The Sample
Ecore Editor doesn't do that for me.
</pre>
</blockquote>
<pre wrap=""><!---->
I mistyped, I meant the Generic EMF Form Editor
It is much more comfortable since it allows jumping from field to field
with tabs.
</pre>
</blockquote>
I'm not sure what that is.<br>
<blockquote cite="mid:8hn267-g2a.ln1@daradja.de" type="cite">
<pre wrap="">IMO the ability of modelling without using the mouse leaves much to be
desired and that editor was a huge step forward.
</pre>
</blockquote>
Yes it would be nice to have time to use EEF to generate nice forms for
EMF.&nbsp; The Ecore Tools editor has nice forms too.<br>
<blockquote cite="mid:8hn267-g2a.ln1@daradja.de" type="cite">
<pre wrap="">
However, it doesn't seem to be a bug there. The Instance Class Name
defaults to java.lang.Object, but when I save the attribute is not
shown. No problem there. I just filled out fields I shouldn't have.
</pre>
</blockquote>
When there is an instance type name specified, the instance class name
is the Java erasure of that name, i.e., for
java.util.List&lt;java.lang.Integer&gt; instance type name it would be
java.util.List instance class name.&nbsp; Since no erasure can be computed
for just a name like Foo, java.lang.Object is assumed.<br>
<br>
<blockquote cite="mid:8hn267-g2a.ln1@daradja.de" type="cite">
<pre wrap="">

While the one problem is now solved, I now have an intresting
second one.
I have an enum as an attribute in a class.

The generated code shows this:

public void eSet(int featureID, Object newValue) {
switch (featureID) {
case SwingtestPackage.PANEL__CHILD_COMPONENTS:
getChildComponents().clear();
getChildComponents().addAll((Collection&lt;? extends Component&gt;)newValue);
return;
case SwingtestPackage.PANEL__MAX_CHILDREN:
setMaxChildren((Integer)newValue);
return;
case SwingtestPackage.PANEL__ORIENTATION:
setOrientation(newValue);
return;
}
super.eSet(featureID, newValue);
}

The command setOrientation(newValue) fails because of the missing cast.
</pre>
</blockquote>
I couldn't reproduce that either, but that's no doubt related to the
instance type name issue too.<br>
<blockquote cite="mid:8hn267-g2a.ln1@daradja.de" type="cite">
<pre wrap="">
Any idea?


&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;ecore:EPackage xmi:version="2.0"
xmlns:xmi=<a class="moz-txt-link-rfc2396E" href="http://www.omg.org/XMI">"http://www.omg.org/XMI"</a>
xmlns:xsi=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/XMLSchema-instance">"http://www.w3.org/2001/XMLSchema-instance"</a>
xmlns:ecore=<a class="moz-txt-link-rfc2396E" href="http://www.eclipse.org/emf/2002/Ecore">"http://www.eclipse.org/emf/2002/Ecore"</a> name="swingtest"
nsURI=<a class="moz-txt-link-rfc2396E" href="http://lm.swingtest.de">"http://lm.swingtest.de"</a> nsPrefix="swingtest"&gt;
&lt;eClassifiers xsi:type="ecore:EClass" name="Panel"
eSuperTypes="#//Component"&gt;
&lt;eStructuralFeatures xsi:type="ecore:EReference" name="childComponents"
upperBound="-1"
eType="#//Component" containment="true"/&gt;
&lt;eStructuralFeatures xsi:type="ecore:EAttribute" name="maxChildren"
lowerBound="1"
eType="ecore:EDataType <a class="moz-txt-link-freetext" href="http://www.eclipse.org/emf/2002/Ecore#//EInt">http://www.eclipse.org/emf/2002/Ecore#//EInt</a>"
defaultValueLiteral="3"/&gt;
&lt;eStructuralFeatures xsi:type="ecore:EAttribute" name="orientation"
lowerBound="1"
eType="#//Orientation" defaultValueLiteral="ROWS"/&gt;
&lt;/eClassifiers&gt;
&lt;eClassifiers xsi:type="ecore:EClass" name="Frame"&gt;
&lt;eStructuralFeatures xsi:type="ecore:EAttribute" name="width"
lowerBound="1" eType="ecore:EDataType
<a class="moz-txt-link-freetext" href="http://www.eclipse.org/emf/2002/Ecore#//EInt">http://www.eclipse.org/emf/2002/Ecore#//EInt</a>"
defaultValueLiteral="300"/&gt;
&lt;eStructuralFeatures xsi:type="ecore:EAttribute" name="height"
lowerBound="1"
eType="ecore:EDataType <a class="moz-txt-link-freetext" href="http://www.eclipse.org/emf/2002/Ecore#//EInt">http://www.eclipse.org/emf/2002/Ecore#//EInt</a>"
defaultValueLiteral="300"/&gt;
&lt;eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
lowerBound="1" eType="ecore:EDataType
<a class="moz-txt-link-freetext" href="http://www.eclipse.org/emf/2002/Ecore#//EString">http://www.eclipse.org/emf/2002/Ecore#//EString</a>"/&gt;
&lt;/eClassifiers&gt;
&lt;eClassifiers xsi:type="ecore:EEnum" name="Orientation"
instanceTypeName="Orientation"&gt;
&lt;eLiterals name="COLUMNS" literal="Columns"/&gt;
&lt;eLiterals name="ROWS" value="1" literal="Rows"/&gt;
&lt;/eClassifiers&gt;
&lt;eClassifiers xsi:type="ecore:EClass" name="Component" abstract="true"/&gt;
&lt;eClassifiers xsi:type="ecore:EClass" name="Button"
eSuperTypes="#//Component"&gt;
&lt;eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
lowerBound="1" eType="ecore:EDataType
<a class="moz-txt-link-freetext" href="http://www.eclipse.org/emf/2002/Ecore#//EString">http://www.eclipse.org/emf/2002/Ecore#//EString</a>"
defaultValueLiteral="A Button"/&gt;
&lt;/eClassifiers&gt;
&lt;/ecore:EPackage&gt;

</pre>
</blockquote>
</body>
</html>

--------------080507060608080907050807--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: No model interfaces generated. Why? [message #518354 is a reply to message #518322] Wed, 03 March 2010 21:01 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33142
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------000600020206050902040503
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Michael,

Comments below.

Michael Lehmeier wrote:
> On 2010-03-03, Michael Lehmeier <m_lehmeier@gmx.de> wrote:
>
>> While the one problem is now solved, I now have an intresting
>> second one.
>> I have an enum as an attribute in a class.
>>
>
> Nevermind.
> I recreated that enum using the orginal editor and now it works.
>
> It seems to me that EMF is really fragile in its usage to those who
> don't know yet most or all of its features.
>
The editor you're using seems to be less than completely helpful. I
wonder if it lets you point an EReference's eOpposite at any other
reference whatsoever?

I wouldn't call it so much fragile. It's doing exactly what you told it
to do, you just didn't know you were telling it to do that.
> Well, I have to keep on learning.
>
Remember when you tried to use Java's generics for the first time?
Didn't you wonder, how is List<?> different from List<Object> and List<?
extends Object>? Does List<? super Object> make sense?

--------------000600020206050902040503
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Michael,<br>
<br>
Comments below.<br>
<br>
Michael Lehmeier wrote:
<blockquote cite="mid:rho267-j6a.ln1@daradja.de" type="cite">
<pre wrap="">On 2010-03-03, Michael Lehmeier <a class="moz-txt-link-rfc2396E" href="mailto:m_lehmeier@gmx.de">&lt;m_lehmeier@gmx.de&gt;</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">While the one problem is now solved, I now have an intresting
second one.
I have an enum as an attribute in a class.
</pre>
</blockquote>
<pre wrap=""><!---->
Nevermind.
I recreated that enum using the orginal editor and now it works.

It seems to me that EMF is really fragile in its usage to those who
don't know yet most or all of its features.
</pre>
</blockquote>
The editor you're using seems to be less than completely helpful.&nbsp; I
wonder if it lets you point an EReference's eOpposite at any other
reference whatsoever?<br>
<br>
I wouldn't call it so much fragile.&nbsp; It's doing exactly what you told
it to do, you just didn't know you were telling it to do that. <br>
<blockquote cite="mid:rho267-j6a.ln1@daradja.de" type="cite">
<pre wrap="">Well, I have to keep on learning.
</pre>
</blockquote>
Remember when you tried to use Java's generics for the first time? &nbsp;
Didn't you wonder, how is List&lt;?&gt; different from
List&lt;Object&gt; and List&lt;? extends Object&gt;? Does List&lt;?
super Object&gt; make sense?<br>
</body>
</html>

--------------000600020206050902040503--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: No model interfaces generated. Why? [message #518362 is a reply to message #518354] Wed, 03 March 2010 16:38 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: m_lehmeier.gmx.de

On 2010-03-03, Ed Merks <Ed.Merks@gmail.com> wrote:
>>
> Remember when you tried to use Java's generics for the first time?
> Didn't you wonder, how is List<?> different from List<Object> and List<?
> extends Object>? Does List<? super Object> make sense?

Oh yes, I remember.
But there is a big difference.
At that moment I had already programmed Java with generics for about one
and a half years at my job.

At this point I tried using Openarchitectureware for two weeks, read the
book on EMF for two days and tried out what I know for more than one day
and have yet to get a simple "Hello World" running.

This is basically what I am trying to do now.
After I had to abandon my OAW project because I failed to connect two
different models. Eclipse gave no error, but OAW crashed.
I guessed my problem was that I didn't know much about the specifics of
EMF yet.

I read much of "EMF - Eclipse Modeling Framework" and wondered where I
could get a real benefit out of it without using a M2T tool. But there must
be a way.
Most tutorials I have seen end with an Eclipse plugin running to edit
models, but don't explain what actually to do with those models.
So I started to make up a little project that should display a dynamic
number of buttons in Swing using EMFi to see for myself.

I'm still not totally sure how to do it.
I spent my last two hourse googling where to get and how to register a
ResourceFactory so I could at least persist a simple model like in
the example in the book.
Turned out I had to read chapter 15.3 in the book so I *may* get the
example from chapter 2.5.2 running...
(Solved that problem by now, BTW)

I'm sorry if I'm ranting, but it does get frustrating in a way that I
never encountered before in an established technology.
But I won't give up!

--
Lehmeier Michael
Re: No model interfaces generated. Why? [message #518379 is a reply to message #518362] Wed, 03 March 2010 22:38 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33142
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------000109060804040000000403
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Michael,

Comments below.

Michael Lehmeier wrote:
> On 2010-03-03, Ed Merks <Ed.Merks@gmail.com> wrote:
>
>>>
>>>
>> Remember when you tried to use Java's generics for the first time?
>> Didn't you wonder, how is List<?> different from List<Object> and List<?
>> extends Object>? Does List<? super Object> make sense?
>>
>
> Oh yes, I remember.
> But there is a big difference.
> At that moment I had already programmed Java with generics for about one
> and a half years at my job.
>
I mean the first time you had to learn generics, did all these things
seem intuitive or obvious? I often ask people to explain, with the <?
super Type> means, and I find that almost nobody can explain it or why
you'd use it...
> At this point I tried using Openarchitectureware for two weeks, read the
> book on EMF for two days and tried out what I know for more than one day
> and have yet to get a simple "Hello World" running.
>
> This is basically what I am trying to do now.
> After I had to abandon my OAW project because I failed to connect two
> different models. Eclipse gave no error, but OAW crashed.
> I guessed my problem was that I didn't know much about the specifics of
> EMF yet.
>
> I read much of "EMF - Eclipse Modeling Framework" and wondered where I
> could get a real benefit out of it without using a M2T tool. But there must
> be a way.
> Most tutorials I have seen end with an Eclipse plugin running to edit
> models, but don't explain what actually to do with those models.
>
That's a little like explaining what to do with data structures in Java.
> So I started to make up a little project that should display a dynamic
> number of buttons in Swing using EMFi to see for myself.
>
> I'm still not totally sure how to do it.
>
One might ask, how would you do it without EMF?
> I spent my last two hourse googling where to get and how to register a
> ResourceFactory so I could at least persist a simple model like in
> the example in the book.
>
Of course if you invoke Generate Test Code the generated XyzExample.java
shows a working example, but how were you to know?
> Turned out I had to read chapter 15.3 in the book so I *may* get the
> example from chapter 2.5.2 running...
> (Solved that problem by now, BTW)
>
> I'm sorry if I'm ranting, but it does get frustrating in a way that I
> never encountered before in an established technology.
>
I've pretty much seen people rant about every technology. E.g., on the
platform newsgroup, for example, so many people just don't get the
concept of a workspace, at first. I've seen probably 1000 people not be
able to figure out how to make plugins compile *and *depend properly on
each other at runtime; no don't modify the build path directly, edit the
MANIFEST.MF. I've seen the web services experts at my previous company
at a complete loss to explain what an IDREF is. I've seen that almost
no one understands fully the implications of putting xmlns="..." in
their XML file; yes, that's right, unqualified elements are now
implicitly qualified, but no, unqualified attributes are not, they
always need explicit qualification. So yes, you need form="qualified"
on your local element declarations or elementFormDefault="qualified" on
your schema element. I could rant on, but the point is that all new
things are confusing at first and then intuitive later.
> But I won't give up!
>
No, and I'll bet you won't regret having put in the effort. It's
amazing how short the transition from hating EMF to liking it can be...

--------------000109060804040000000403
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Michael,<br>
<br>
Comments below.<br>
<br>
Michael Lehmeier wrote:
<blockquote cite="mid:vk0367-2bc.ln1@daradja.de" type="cite">
<pre wrap="">On 2010-03-03, Ed Merks <a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com">&lt;Ed.Merks@gmail.com&gt;</a> wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">Remember when you tried to use Java's generics for the first time?
Didn't you wonder, how is List&lt;?&gt; different from List&lt;Object&gt; and List&lt;?
extends Object&gt;? Does List&lt;? super Object&gt; make sense?
</pre>
</blockquote>
<pre wrap=""><!---->
Oh yes, I remember.
But there is a big difference.
At that moment I had already programmed Java with generics for about one
and a half years at my job.
</pre>
</blockquote>
I mean the first time you had to learn generics, did all these things
seem intuitive or obvious?&nbsp; I often ask people to explain, with the
&lt;? super Type&gt; means, and I find that almost nobody can explain
it or why you'd use it...<br>
<blockquote cite="mid:vk0367-2bc.ln1@daradja.de" type="cite">
<pre wrap="">
At this point I tried using Openarchitectureware for two weeks, read the
book on EMF for two days and tried out what I know for more than one day
and have yet to get a simple "Hello World" running.

This is basically what I am trying to do now.
After I had to abandon my OAW project because I failed to connect two
different models. Eclipse gave no error, but OAW crashed.
I guessed my problem was that I didn't know much about the specifics of
EMF yet.

I read much of "EMF - Eclipse Modeling Framework" and wondered where I
could get a real benefit out of it without using a M2T tool. But there must
be a way.
Most tutorials I have seen end with an Eclipse plugin running to edit
models, but don't explain what actually to do with those models.
</pre>
</blockquote>
That's a little like explaining what to do with data structures in Java.<br>
<blockquote cite="mid:vk0367-2bc.ln1@daradja.de" type="cite">
<pre wrap="">So I started to make up a little project that should display a dynamic
number of buttons in Swing using EMFi to see for myself.

I'm still not totally sure how to do it.
</pre>
</blockquote>
One might ask, how would you do it without EMF?&nbsp; <br>
<blockquote cite="mid:vk0367-2bc.ln1@daradja.de" type="cite">
<pre wrap="">I spent my last two hourse googling where to get and how to register a
ResourceFactory so I could at least persist a simple model like in
the example in the book.
</pre>
</blockquote>
Of course if you invoke Generate Test Code the generated
XyzExample.java shows a working example, but how were you to know?<br>
<blockquote cite="mid:vk0367-2bc.ln1@daradja.de" type="cite">
<pre wrap="">Turned out I had to read chapter 15.3 in the book so I *may* get the
example from chapter 2.5.2 running...
(Solved that problem by now, BTW)

I'm sorry if I'm ranting, but it does get frustrating in a way that I
never encountered before in an established technology.
</pre>
</blockquote>
I've pretty much seen people rant about every technology.&nbsp; E.g., on the
platform newsgroup, for example, so many people just don't get the
concept of a workspace, at first.&nbsp; I've seen probably 1000 people not
be able to figure out how to make plugins compile <b>and </b>depend
properly on each other at runtime; no don't modify the build path
directly, edit the MANIFEST.MF.&nbsp; I've seen the web services experts at
my previous company at a complete loss to explain what an IDREF is.&nbsp;
I've seen that almost no one understands fully the implications of
putting xmlns="..." in their XML file; yes, that's right, unqualified
elements are now implicitly qualified, but no, unqualified attributes
are not, they always need explicit qualification.&nbsp; So yes, you need
form="qualified" on your local element declarations or
elementFormDefault="qualified" on your schema element.&nbsp; I could rant
on, but the point is that all new things are confusing at first and
then intuitive later.<br>
<blockquote cite="mid:vk0367-2bc.ln1@daradja.de" type="cite">
<pre wrap="">But I won't give up!
</pre>
</blockquote>
No, and I'll bet you won't regret having put in the effort.&nbsp; It's
amazing how short the transition from hating EMF to liking it can be...<br>
</body>
</html>

--------------000109060804040000000403--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: No model interfaces generated. Why? [message #518530 is a reply to message #518379] Thu, 04 March 2010 12:04 Go to previous message
Eclipse UserFriend
Originally posted by: m_lehmeier.gmx.de

On 2010-03-03, Ed Merks <Ed.Merks@gmail.com> wrote:
> Michael Lehmeier wrote:
>> On 2010-03-03, Ed Merks <Ed.Merks@gmail.com> wrote:
>>
>> Oh yes, I remember.
>> But there is a big difference.
>> At that moment I had already programmed Java with generics for about one
>> and a half years at my job.
>>
> I mean the first time you had to learn generics, did all these things
> seem intuitive or obvious? I often ask people to explain, with the <?
> super Type> means, and I find that almost nobody can explain it or why
> you'd use it...

Generics in general were (at least to me) pretty easy and intuitive to
understand. Tools like Eclipse make developing with them very easy, so
there wasn't a big transition.
The only thing that was more complicated is the <? super ..> and <?
extends ...> and you don't have to bother with them when you use
interfaces or base classes. You only have to know how they work when you
*write* interfaces and base classes.
It turned out that there was no one I was working with who bothered to
add generics to our base classes. It was I who suggested that there must
be a better way to do stuff and yes, it took two days to fully
understand how these generics work and another week to convert our
classes to use them properly.

In the end, it was really worth it and we learned a lot from it.
This is why I can really relate to your example. And why I think that
MDA is really worth the trouble.
But my point still stands: In Java, you can get working results sooner,
with much less learning. MDA and EMF demands much more.

>> So I started to make up a little project that should display a dynamic
>> number of buttons in Swing using EMFi to see for myself.
>>
>> I'm still not totally sure how to do it.
>>
> One might ask, how would you do it without EMF?

I have met quite a couple of GUI programmers (usually web) and only one
of them has even heared of EMF.
So I guess there has to be a way. ;)

Anyway, in my current example project I made a little sample Swing
application that just contains a couple of buttons. Rearranging the
buttons in Java code is pretty easy, but would get more difficult if the
GUI becomes more complex. The system that I work on in my job is still
maintained manually, but it is already pretty complex and it gets on my
nerves.
So I tried how to configure the Swing layout using plain EMF, with just
the generated models. So far I only used EMF models to generate code
using Expand and Xtend, but now I wanted to try it only by modifying the
generated model classes.

Yesterday evening I finally succeeded and am pretty pleased with my
result.
But I also see some limitations, which is why I will probably go back to
M2T with Expand and Xtend for my more complex project. But I feel like I
can now handle the problems I had there better.

I guess my biggest problem was that the OAW video tutorials made it all
look too easy so I started with a too complex project.
Now I'm back to step by step.

>> I spent my last two hourse googling where to get and how to register a
>> ResourceFactory so I could at least persist a simple model like in
>> the example in the book.
>>
> Of course if you invoke Generate Test Code the generated XyzExample.java
> shows a working example, but how were you to know?

Well, it never occured to me to use those tests until I have a working
project, so I never looked at the code.
Yes, this looks pretty much like I eventually solved the problem.

>> I'm sorry if I'm ranting, but it does get frustrating in a way that I
>> never encountered before in an established technology.
>>
> I've pretty much seen people rant about every technology. E.g., on the
> platform newsgroup, for example, so many people just don't get

<snip>

*giggle*
Oh yes, good examples.

> I could rant on, but the point is that all new
> things are confusing at first and then intuitive later.

>> But I won't give up!
>>
> No, and I'll bet you won't regret having put in the effort. It's
> amazing how short the transition from hating EMF to liking it can be...

I'm not yet down to hating EMF. Hopefully I won't get there and go
straight to liking it.

I want to thank you once more for your help.
When I have the time I may put together my Swing example into some sort
of tutorial or at least as an example how everything could work.

--
Lehmeier Michael
Re: No model interfaces generated. Why? [message #518564 is a reply to message #518530] Thu, 04 March 2010 08:58 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33142
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------090806020908060002080208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Michael,

Comments below.

Michael Lehmeier wrote:
> On 2010-03-03, Ed Merks <Ed.Merks@gmail.com> wrote:
>
>> Michael Lehmeier wrote:
>>
>>> On 2010-03-03, Ed Merks <Ed.Merks@gmail.com> wrote:
>>>
>>> Oh yes, I remember.
>>> But there is a big difference.
>>> At that moment I had already programmed Java with generics for about one
>>> and a half years at my job.
>>>
>>>
>> I mean the first time you had to learn generics, did all these things
>> seem intuitive or obvious? I often ask people to explain, with the <?
>> super Type> means, and I find that almost nobody can explain it or why
>> you'd use it...
>>
>
> Generics in general were (at least to me) pretty easy and intuitive to
> understand. Tools like Eclipse make developing with them very easy, so
> there wasn't a big transition.
> The only thing that was more complicated is the <? super ..> and <?
> extends ...> and you don't have to bother with them when you use
> interfaces or base classes. You only have to know how they work when you
> *write* interfaces and base classes.
>
Well, that's not entirely true, but yes, my first encounter was when I
had to templatize EMF's runtime. I was slightly horrified by the
complexity of it all.
> It turned out that there was no one I was working with who bothered to
> add generics to our base classes. It was I who suggested that there must
> be a better way to do stuff and yes, it took two days to fully
> understand how these generics work and another week to convert our
> classes to use them properly.
>
I find that even after understanding <? super ...> it slips from one's
mind again very quickly...
> In the end, it was really worth it and we learned a lot from it.
>
Yes, I can't imagine living without now.
> This is why I can really relate to your example. And why I think that
> MDA is really worth the trouble.
> But my point still stands: In Java, you can get working results sooner,
> with much less learning. MDA and EMF demands much more.
>
I'm not sure that's entirely true given that Java is far more complex
than Ecore. But yes, Eclipse's Java tools are slick as can be while the
Ecore tools are crude by comparison.
>
>>> So I started to make up a little project that should display a dynamic
>>> number of buttons in Swing using EMFi to see for myself.
>>>
>>> I'm still not totally sure how to do it.
>>>
>>>
>> One might ask, how would you do it without EMF?
>>
>
> I have met quite a couple of GUI programmers (usually web) and only one
> of them has even heared of EMF.
> So I guess there has to be a way. ;)
>
Clearly. People generally write Beans, which is tedious, and then
issues like notification need to be addressed. One way to look at Ecore
is you only have to say I have a class X with feature y of type Z and
you're done. Hit some buttons, out comes an interface X, a class XImpl,
a factory for creating an X, getters and setters for y in both the
interface and the class, a variable to store y, notification support so
you can view X, serialization framework so you can persist X to XML, and
so on. I.e., you get a lot of Java stuff with only a tiny specification...
> Anyway, in my current example project I made a little sample Swing
> application that just contains a couple of buttons. Rearranging the
> buttons in Java code is pretty easy, but would get more difficult if the
> GUI becomes more complex. The system that I work on in my job is still
> maintained manually, but it is already pretty complex and it gets on my
> nerves.
>
Yes, smart people find ways to automate tedious things a computer can do
better and find challenge in that task, while stupid people relish
feeling busy even with pointless activity and find comfort in their
ignorance.
> So I tried how to configure the Swing layout using plain EMF, with just
> the generated models. So far I only used EMF models to generate code
> using Expand and Xtend, but now I wanted to try it only by modifying the
> generated model classes.
>
Was this a model for specifying how the layout should look? One thing
to always consider is that if you can generate code from it, you can
probably emulate the behavior without ever generating a line of code.
E.g., you can generate a whole whack of Java code from an Ecore model,
but you can also create instances of that model without generating a
single line of code...
> Yesterday evening I finally succeeded and am pretty pleased with my
> result.
> But I also see some limitations, which is why I will probably go back to
> M2T with Expand and Xtend for my more complex project. But I feel like I
> can now handle the problems I had there better.
>
> I guess my biggest problem was that the OAW video tutorials made it all
> look too easy so I started with a too complex project.
> Now I'm back to step by step.
>
We're always impatient to move on to more interesting things, but
sometimes it's necessary to take those little steps first.
>
>>> I spent my last two hourse googling where to get and how to register a
>>> ResourceFactory so I could at least persist a simple model like in
>>> the example in the book.
>>>
>>>
>> Of course if you invoke Generate Test Code the generated XyzExample.java
>> shows a working example, but how were you to know?
>>
>
> Well, it never occured to me to use those tests until I have a working
> project, so I never looked at the code.
> Yes, this looks pretty much like I eventually solved the problem.
>
The question was asked so many times, I decided to generate an answer. :-P
>
>>> I'm sorry if I'm ranting, but it does get frustrating in a way that I
>>> never encountered before in an established technology.
>>>
>>>
>> I've pretty much seen people rant about every technology. E.g., on the
>> platform newsgroup, for example, so many people just don't get
>>
>
> <snip>
>
> *giggle*
> Oh yes, good examples.
>
>
>> I could rant on, but the point is that all new
>> things are confusing at first and then intuitive later.
>>
>
>
>>> But I won't give up!
>>>
>>>
>> No, and I'll bet you won't regret having put in the effort. It's
>> amazing how short the transition from hating EMF to liking it can be...
>>
>
> I'm not yet down to hating EMF. Hopefully I won't get there and go
> straight to liking it.
>
> I want to thank you once more for your help.
>
:-)
> When I have the time I may put together my Swing example into some sort
> of tutorial or at least as an example how everything could work.
>
>

--------------090806020908060002080208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Michael,<br>
<br>
Comments below.<br>
<br>
Michael Lehmeier wrote:
<blockquote cite="mid:g7k467-la4.ln1@daradja.de" type="cite">
<pre wrap="">On 2010-03-03, Ed Merks <a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com">&lt;Ed.Merks@gmail.com&gt;</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Michael Lehmeier wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 2010-03-03, Ed Merks <a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com">&lt;Ed.Merks@gmail.com&gt;</a> wrote:

Oh yes, I remember.
But there is a big difference.
At that moment I had already programmed Java with generics for about one
and a half years at my job.

</pre>
</blockquote>
<pre wrap="">I mean the first time you had to learn generics, did all these things
seem intuitive or obvious? I often ask people to explain, with the &lt;?
super Type&gt; means, and I find that almost nobody can explain it or why
you'd use it...
</pre>
</blockquote>
<pre wrap=""><!---->
Generics in general were (at least to me) pretty easy and intuitive to
understand. Tools like Eclipse make developing with them very easy, so
there wasn't a big transition.
The only thing that was more complicated is the &lt;? super ..&gt; and &lt;?
extends ...&gt; and you don't have to bother with them when you use
interfaces or base classes. You only have to know how they work when you
*write* interfaces and base classes.
</pre>
</blockquote>
Well, that's not entirely true, but yes, my first encounter was when I
had to templatize EMF's runtime.&nbsp; I was slightly horrified by the
complexity of it all.<br>
<blockquote cite="mid:g7k467-la4.ln1@daradja.de" type="cite">
<pre wrap="">It turned out that there was no one I was working with who bothered to
add generics to our base classes. It was I who suggested that there must
be a better way to do stuff and yes, it took two days to fully
understand how these generics work and another week to convert our
classes to use them properly.
</pre>
</blockquote>
I find that even after understanding &lt;? super ...&gt; it slips from
one's mind again very quickly...<br>
<blockquote cite="mid:g7k467-la4.ln1@daradja.de" type="cite">
<pre wrap="">
In the end, it was really worth it and we learned a lot from it.
</pre>
</blockquote>
Yes, I can't imagine living without now.<br>
<blockquote cite="mid:g7k467-la4.ln1@daradja.de" type="cite">
<pre wrap="">This is why I can really relate to your example. And why I think that
MDA is really worth the trouble.
But my point still stands: In Java, you can get working results sooner,
with much less learning. MDA and EMF demands much more.
</pre>
</blockquote>
I'm not sure that's entirely true given that Java is far more complex
than Ecore.&nbsp; But yes, Eclipse's Java tools are slick as can be while
the Ecore tools are crude by comparison. <br>
<blockquote cite="mid:g7k467-la4.ln1@daradja.de" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">So I started to make up a little project that should display a dynamic
number of buttons in Swing using EMFi to see for myself.

I'm still not totally sure how to do it.

</pre>
</blockquote>
<pre wrap="">One might ask, how would you do it without EMF?
</pre>
</blockquote>
<pre wrap=""><!---->
I have met quite a couple of GUI programmers (usually web) and only one
of them has even heared of EMF.
So I guess there has to be a way. ;)
</pre>
</blockquote>
Clearly.&nbsp; People generally write Beans, which is tedious, and then
issues like notification need to be addressed.&nbsp; One way to look at
Ecore is you only have to say I have a class X with feature y of type Z
and you're done.&nbsp; Hit some buttons, out comes an interface X, a class
XImpl, a factory for creating an X, getters and setters for y in both
the interface and the class, a variable to store y, notification
support so you can view X, serialization framework so you can persist X
to XML, and so on.&nbsp; I.e., you get a lot of Java stuff with only a tiny
specification...<br>
<blockquote cite="mid:g7k467-la4.ln1@daradja.de" type="cite">
<pre wrap="">
Anyway, in my current example project I made a little sample Swing
application that just contains a couple of buttons. Rearranging the
buttons in Java code is pretty easy, but would get more difficult if the
GUI becomes more complex. The system that I work on in my job is still
maintained manually, but it is already pretty complex and it gets on my
nerves.
</pre>
</blockquote>
Yes, smart people find ways to automate tedious things a computer can
do better and find challenge in that task, while stupid people relish
feeling busy even with pointless activity and find comfort in their
ignorance.<br>
<blockquote cite="mid:g7k467-la4.ln1@daradja.de" type="cite">
<pre wrap="">So I tried how to configure the Swing layout using plain EMF, with just
the generated models. So far I only used EMF models to generate code
using Expand and Xtend, but now I wanted to try it only by modifying the
generated model classes.
</pre>
</blockquote>
Was this a model for specifying how the layout should look?&nbsp; One thing
to always consider is that if you can generate code from it, you can
probably emulate the behavior without ever generating a line of code.&nbsp;
E.g., you can generate a whole whack of Java code from an Ecore model,
but you can also create instances of that model without generating a
single line of code...<br>
<blockquote cite="mid:g7k467-la4.ln1@daradja.de" type="cite">
<pre wrap="">
Yesterday evening I finally succeeded and am pretty pleased with my
result.
But I also see some limitations, which is why I will probably go back to
M2T with Expand and Xtend for my more complex project. But I feel like I
can now handle the problems I had there better.

I guess my biggest problem was that the OAW video tutorials made it all
look too easy so I started with a too complex project.
Now I'm back to step by step.
</pre>
</blockquote>
We're always impatient to move on to more interesting things, but
sometimes it's necessary to take those little steps first.<br>
<blockquote cite="mid:g7k467-la4.ln1@daradja.de" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I spent my last two hourse googling where to get and how to register a
ResourceFactory so I could at least persist a simple model like in
the example in the book.

</pre>
</blockquote>
<pre wrap="">Of course if you invoke Generate Test Code the generated XyzExample.java
shows a working example, but how were you to know?
</pre>
</blockquote>
<pre wrap=""><!---->
Well, it never occured to me to use those tests until I have a working
project, so I never looked at the code.
Yes, this looks pretty much like I eventually solved the problem.
</pre>
</blockquote>
The question was asked so many times, I decided to generate an answer.
:-P<br>
<blockquote cite="mid:g7k467-la4.ln1@daradja.de" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I'm sorry if I'm ranting, but it does get frustrating in a way that I
never encountered before in an established technology.

</pre>
</blockquote>
<pre wrap="">I've pretty much seen people rant about every technology. E.g., on the
platform newsgroup, for example, so many people just don't get
</pre>
</blockquote>
<pre wrap=""><!---->
&lt;snip&gt;

*giggle*
Oh yes, good examples.

</pre>
<blockquote type="cite">
<pre wrap="">I could rant on, but the point is that all new
things are confusing at first and then intuitive later.
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">But I won't give up!

</pre>
</blockquote>
<pre wrap="">No, and I'll bet you won't regret having put in the effort. It's
amazing how short the transition from hating EMF to liking it can be...
</pre>
</blockquote>
<pre wrap=""><!---->
I'm not yet down to hating EMF. Hopefully I won't get there and go
straight to liking it.

I want to thank you once more for your help.
</pre>
</blockquote>
:-)<br>
<blockquote cite="mid:g7k467-la4.ln1@daradja.de" type="cite">
<pre wrap="">When I have the time I may put together my Swing example into some sort
of tutorial or at least as an example how everything could work.

</pre>
</blockquote>
</body>
</html>

--------------090806020908060002080208--


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:[CDO Teneo Hibernate Store] Unable to instantiate default tuplizer
Next Topic:Problems with dynamic AND generated EMF
Goto Forum:
  


Current Time: Fri Apr 26 08:44:04 GMT 2024

Powered by FUDForum. Page generated in 0.04359 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top