Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » EMF JET Template Class.javajet - Problems with changes
EMF JET Template Class.javajet - Problems with changes [message #420176] Fri, 20 June 2008 12:35 Go to next message
Marc Moser is currently offline Marc MoserFriend
Messages: 66
Registered: July 2009
Member
Hi,

We use an EMF OCL integration as explained in
http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
Unfortunately, code generation based on our adapted templates stopped
working with build M7 and newer (we are using RC4 right now). But it
worked fine up to and including build M6.

I could identify the "root of this problem" in the EMF template
Class.javajet. Prior to M7, lines 277-285 looked as follows:

protected boolean <%=genFeature.getUncapName()%>ESet;

<%}%>
<%}%>
<%}%>
<%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
fail="silent" %>
<%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
<%}%>
<%if (isImplementation && genClass.hasOffsetCorrection() &&
!genClass.getImplementedGenFeatures().isEmpty()) {%>

Now in RC4, the corresponding lines 306-314 look as follows:

protected boolean <%=genFeature.getUncapName()%>ESet;

<%}%>
<%}%>
<%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
fail="silent" %>
<%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
<%}%>
<%}%>
<%if (isImplementation && genClass.hasOffsetCorrection() &&
!genClass.getImplementedGenFeatures().isEmpty()) {%>

As you can see, one of the closing curly brace <%}%> was moved from
before including declaredFieldGenFeature.insert.javajetinc to after
including it.

Is there a reason for this new behavior, or was this accidentally (ok,
I am pretty sure there is a reason :-)? Also note that this closing
brace actually closes a for-loop, so while before the insert template
was inserted after the for loop, it is now inside the iteration of the
foor loop.

In our case this leads to several problems. We added e.g. a field to
each class by simply declaring it in
Class/declaredFieldGenFeature.insert.javajetinc Now, this doesn't work
anymore because the field will be generated several times because
Class/declaredFieldGenFeature.insert.javajetinc is called inside a
loop. There are also naming clashes now, and other problems.

Thanks for your help!

Best,
Marc
Re: EMF JET Template Class.javajet - Problems with changes [message #420183 is a reply to message #420176] Fri, 20 June 2008 13:18 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33140
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------060503070105040103070904
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Marc,

Comments beow.

Marc Moser wrote:
> Hi,
>
> We use an EMF OCL integration as explained in
> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
> Unfortunately, code generation based on our adapted templates stopped
> working with build M7 and newer (we are using RC4 right now). But it
> worked fine up to and including build M6.
>
> I could identify the "root of this problem" in the EMF template
> Class.javajet. Prior to M7, lines 277-285 looked as follows:
>
> protected boolean <%=genFeature.getUncapName()%>ESet;
>
> <%}%>
> <%}%>
> <%}%>
> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
> fail="silent" %>
> <%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
> <%}%>
> <%if (isImplementation && genClass.hasOffsetCorrection() &&
> !genClass.getImplementedGenFeatures().isEmpty()) {%>
>
> Now in RC4, the corresponding lines 306-314 look as follows:
>
> protected boolean <%=genFeature.getUncapName()%>ESet;
>
> <%}%>
> <%}%>
> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
> fail="silent" %>
> <%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
> <%}%>
> <%}%>
> <%if (isImplementation && genClass.hasOffsetCorrection() &&
> !genClass.getImplementedGenFeatures().isEmpty()) {%>
>
> As you can see, one of the closing curly brace <%}%> was moved from
> before including declaredFieldGenFeature.insert.javajetinc to after
> including it.
>
> Is there a reason for this new behavior, or was this accidentally (ok,
> I am pretty sure there is a reason :-)?

https://bugs.eclipse.org/bugs/show_bug.cgi?id=230410

> Also note that this closing
> brace actually closes a for-loop, so while before the insert template
> was inserted after the for loop, it is now inside the iteration of the
> foor loop.
>
Maybe I screwed it up...
> In our case this leads to several problems. We added e.g. a field to
> each class by simply declaring it in
> Class/declaredFieldGenFeature.insert.javajetinc Now, this doesn't work
> anymore because the field will be generated several times because
> Class/declaredFieldGenFeature.insert.javajetinc is called inside a
> loop. There are also naming clashes now, and other problems.
>
Hmmm. I'm not sure I did screw up though. I think this template should
be invoked once per feature so you'd better be sure the code generated
is different for each feature...
> Thanks for your help!
>
> Best,
> Marc
>


--------------060503070105040103070904
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">
Marc,<br>
<br>
Comments beow.<br>
<br>
Marc Moser wrote:
<blockquote cite="mid:9m7n54hu7aacpm8461qugg1rkpipqsr4ua@4ax.com"
type="cite">
<pre wrap="">Hi,

We use an EMF OCL integration as explained in
<a class="moz-txt-link-freetext" href=" http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html"> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html</a>
Unfortunately, code generation based on our adapted templates stopped
working with build M7 and newer (we are using RC4 right now). But it
worked fine up to and including build M6.

I could identify the "root of this problem" in the EMF template
Class.javajet. Prior to M7, lines 277-285 looked as follows:

protected boolean &lt;%=genFeature.getUncapName()%&gt;ESet;

&lt;%}%&gt;
&lt;%}%&gt;
&lt;%}%&gt;
&lt;%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
fail="silent" %&gt;
&lt;%@ end %&gt;&lt;%//Class/declaredFieldGenFeature.override.j avajetinc%&gt;
&lt;%}%&gt;
&lt;%if (isImplementation &amp;&amp; genClass.hasOffsetCorrection() &amp;&amp;
!genClass.getImplementedGenFeatures().isEmpty()) {%&gt;

Now in RC4, the corresponding lines 306-314 look as follows:

protected boolean &lt;%=genFeature.getUncapName()%&gt;ESet;

&lt;%}%&gt;
&lt;%}%&gt;
&lt;%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
fail="silent" %&gt;
&lt;%@ end %&gt;&lt;%//Class/declaredFieldGenFeature.override.j avajetinc%&gt;
&lt;%}%&gt;
&lt;%}%&gt;
&lt;%if (isImplementation &amp;&amp; genClass.hasOffsetCorrection() &amp;&amp;
!genClass.getImplementedGenFeatures().isEmpty()) {%&gt;

As you can see, one of the closing curly brace &lt;%}%&gt; was moved from
before including declaredFieldGenFeature.insert.javajetinc to after
including it.

Is there a reason for this new behavior, or was this accidentally (ok,
I am pretty sure there is a reason :-)?</pre>
</blockquote>
<blockquote><a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=230410">https://bugs.eclipse.org/bugs/show_bug.cgi?id=230410</a><br>
</blockquote>
<blockquote cite="mid:9m7n54hu7aacpm8461qugg1rkpipqsr4ua@4ax.com"
type="cite">
<pre wrap=""> Also note that this closing
brace actually closes a for-loop, so while before the insert template
was inserted after the for loop, it is now inside the iteration of the
foor loop.
</pre>
</blockquote>
Maybe I screwed it up...<br>
<blockquote cite="mid:9m7n54hu7aacpm8461qugg1rkpipqsr4ua@4ax.com"
type="cite">
<pre wrap="">
In our case this leads to several problems. We added e.g. a field to
each class by simply declaring it in
Class/declaredFieldGenFeature.insert.javajetinc Now, this doesn't work
anymore because the field will be generated several times because
Class/declaredFieldGenFeature.insert.javajetinc is called inside a
loop. There are also naming clashes now, and other problems.
</pre>
</blockquote>
Hmmm.&nbsp; I'm not sure I did screw up though.&nbsp; I think this template
should be invoked once per feature so you'd better be sure the code
generated is different for each feature...<br>
<blockquote cite="mid:9m7n54hu7aacpm8461qugg1rkpipqsr4ua@4ax.com"
type="cite">
<pre wrap="">
Thanks for your help!

Best,
Marc
</pre>
</blockquote>
<br>
</body>
</html>

--------------060503070105040103070904--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF JET Template Class.javajet - Problems with changes [message #420186 is a reply to message #420183] Fri, 20 June 2008 13:49 Go to previous messageGo to next message
Marc Moser is currently offline Marc MoserFriend
Messages: 66
Registered: July 2009
Member
Hi Ed,

Comments below.

>Marc,
>
>Comments beow.
>
>Marc Moser wrote:
>> Hi,
>>
>> We use an EMF OCL integration as explained in
>> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
>> Unfortunately, code generation based on our adapted templates stopped
>> working with build M7 and newer (we are using RC4 right now). But it
>> worked fine up to and including build M6.
>>
>> I could identify the "root of this problem" in the EMF template
>> Class.javajet. Prior to M7, lines 277-285 looked as follows:
>>
>> protected boolean <%=genFeature.getUncapName()%>ESet;
>>
>> <%}%>
>> <%}%>
>> <%}%>
>> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
>> fail="silent" %>
>> <%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
>> <%}%>
>> <%if (isImplementation && genClass.hasOffsetCorrection() &&
>> !genClass.getImplementedGenFeatures().isEmpty()) {%>
>>
>> Now in RC4, the corresponding lines 306-314 look as follows:
>>
>> protected boolean <%=genFeature.getUncapName()%>ESet;
>>
>> <%}%>
>> <%}%>
>> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
>> fail="silent" %>
>> <%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
>> <%}%>
>> <%}%>
>> <%if (isImplementation && genClass.hasOffsetCorrection() &&
>> !genClass.getImplementedGenFeatures().isEmpty()) {%>
>>
>> As you can see, one of the closing curly brace <%}%> was moved from
>> before including declaredFieldGenFeature.insert.javajetinc to after
>> including it.
>>
>> Is there a reason for this new behavior, or was this accidentally (ok,
>> I am pretty sure there is a reason :-)?
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=230410
>
>> Also note that this closing
>> brace actually closes a for-loop, so while before the insert template
>> was inserted after the for loop, it is now inside the iteration of the
>> foor loop.
>>
>Maybe I screwed it up...
>> In our case this leads to several problems. We added e.g. a field to
>> each class by simply declaring it in
>> Class/declaredFieldGenFeature.insert.javajetinc Now, this doesn't work
>> anymore because the field will be generated several times because
>> Class/declaredFieldGenFeature.insert.javajetinc is called inside a
>> loop. There are also naming clashes now, and other problems.
>>
>Hmmm. I'm not sure I did screw up though. I think this template should
>be invoked once per feature so you'd better be sure the code generated
>is different for each feature...

So far, the insert-template was called only once and the override
template did not work. Now with the bug fix, the override template
works, but the fix also changes the way the insert-tamplate is called,
because now it is called once per feature. But I agree with you that
this is probably how it should have been from the beginning. Thus, if
you tell me it will stay the way it is now, I'm happy with it and I'll
adapt my templates accordingly.

>> Thanks for your help!
>>
>> Best,
>> Marc
>>
Re: EMF JET Template Class.javajet - Problems with changes [message #420189 is a reply to message #420186] Fri, 20 June 2008 15:06 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33140
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------040802030203000800040007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Marc,

Yes, I think it was wrong before and it should stay the way it is now.


Marc Moser wrote:
> Hi Ed,
>
> Comments below.
>
>
>> Marc,
>>
>> Comments beow.
>>
>> Marc Moser wrote:
>>
>>> Hi,
>>>
>>> We use an EMF OCL integration as explained in
>>> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
>>> Unfortunately, code generation based on our adapted templates stopped
>>> working with build M7 and newer (we are using RC4 right now). But it
>>> worked fine up to and including build M6.
>>>
>>> I could identify the "root of this problem" in the EMF template
>>> Class.javajet. Prior to M7, lines 277-285 looked as follows:
>>>
>>> protected boolean <%=genFeature.getUncapName()%>ESet;
>>>
>>> <%}%>
>>> <%}%>
>>> <%}%>
>>> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
>>> fail="silent" %>
>>> <%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
>>> <%}%>
>>> <%if (isImplementation && genClass.hasOffsetCorrection() &&
>>> !genClass.getImplementedGenFeatures().isEmpty()) {%>
>>>
>>> Now in RC4, the corresponding lines 306-314 look as follows:
>>>
>>> protected boolean <%=genFeature.getUncapName()%>ESet;
>>>
>>> <%}%>
>>> <%}%>
>>> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
>>> fail="silent" %>
>>> <%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
>>> <%}%>
>>> <%}%>
>>> <%if (isImplementation && genClass.hasOffsetCorrection() &&
>>> !genClass.getImplementedGenFeatures().isEmpty()) {%>
>>>
>>> As you can see, one of the closing curly brace <%}%> was moved from
>>> before including declaredFieldGenFeature.insert.javajetinc to after
>>> including it.
>>>
>>> Is there a reason for this new behavior, or was this accidentally (ok,
>>> I am pretty sure there is a reason :-)?
>>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=230410
>>
>>
>>> Also note that this closing
>>> brace actually closes a for-loop, so while before the insert template
>>> was inserted after the for loop, it is now inside the iteration of the
>>> foor loop.
>>>
>>>
>> Maybe I screwed it up...
>>
>>> In our case this leads to several problems. We added e.g. a field to
>>> each class by simply declaring it in
>>> Class/declaredFieldGenFeature.insert.javajetinc Now, this doesn't work
>>> anymore because the field will be generated several times because
>>> Class/declaredFieldGenFeature.insert.javajetinc is called inside a
>>> loop. There are also naming clashes now, and other problems.
>>>
>>>
>> Hmmm. I'm not sure I did screw up though. I think this template should
>> be invoked once per feature so you'd better be sure the code generated
>> is different for each feature...
>>
>
> So far, the insert-template was called only once and the override
> template did not work. Now with the bug fix, the override template
> works, but the fix also changes the way the insert-tamplate is called,
> because now it is called once per feature. But I agree with you that
> this is probably how it should have been from the beginning. Thus, if
> you tell me it will stay the way it is now, I'm happy with it and I'll
> adapt my templates accordingly.
>
>
>>> Thanks for your help!
>>>
>>> Best,
>>> Marc
>>>
>>>


--------------040802030203000800040007
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">
Marc,<br>
<br>
Yes, I think it was wrong before and it should stay the way it is now.<br>
<br>
<br>
Marc Moser wrote:
<blockquote cite="mid:mmcn54hc7pn871l2lbhgcng19d9ntb44jk@4ax.com"
type="cite">
<pre wrap="">Hi Ed,

Comments below.

</pre>
<blockquote type="cite">
<pre wrap="">Marc,

Comments beow.

Marc Moser wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,

We use an EMF OCL integration as explained in
<a class="moz-txt-link-freetext" href=" http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html"> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html</a>
Unfortunately, code generation based on our adapted templates stopped
working with build M7 and newer (we are using RC4 right now). But it
worked fine up to and including build M6.

I could identify the "root of this problem" in the EMF template
Class.javajet. Prior to M7, lines 277-285 looked as follows:

protected boolean &lt;%=genFeature.getUncapName()%&gt;ESet;

&lt;%}%&gt;
&lt;%}%&gt;
&lt;%}%&gt;
&lt;%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
fail="silent" %&gt;
&lt;%@ end %&gt;&lt;%//Class/declaredFieldGenFeature.override.j avajetinc%&gt;
&lt;%}%&gt;
&lt;%if (isImplementation &amp;&amp; genClass.hasOffsetCorrection() &amp;&amp;
!genClass.getImplementedGenFeatures().isEmpty()) {%&gt;

Now in RC4, the corresponding lines 306-314 look as follows:

protected boolean &lt;%=genFeature.getUncapName()%&gt;ESet;

&lt;%}%&gt;
&lt;%}%&gt;
&lt;%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
fail="silent" %&gt;
&lt;%@ end %&gt;&lt;%//Class/declaredFieldGenFeature.override.j avajetinc%&gt;
&lt;%}%&gt;
&lt;%}%&gt;
&lt;%if (isImplementation &amp;&amp; genClass.hasOffsetCorrection() &amp;&amp;
!genClass.getImplementedGenFeatures().isEmpty()) {%&gt;

As you can see, one of the closing curly brace &lt;%}%&gt; was moved from
before including declaredFieldGenFeature.insert.javajetinc to after
including it.

Is there a reason for this new behavior, or was this accidentally (ok,
I am pretty sure there is a reason :-)?
</pre>
</blockquote>
<pre wrap=""> <a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=230410">https://bugs.eclipse.org/bugs/show_bug.cgi?id=230410</a>

</pre>
<blockquote type="cite">
<pre wrap=""> Also note that this closing
brace actually closes a for-loop, so while before the insert template
was inserted after the for loop, it is now inside the iteration of the
foor loop.

</pre>
</blockquote>
<pre wrap="">Maybe I screwed it up...
</pre>
<blockquote type="cite">
<pre wrap="">In our case this leads to several problems. We added e.g. a field to
each class by simply declaring it in
Class/declaredFieldGenFeature.insert.javajetinc Now, this doesn't work
anymore because the field will be generated several times because
Class/declaredFieldGenFeature.insert.javajetinc is called inside a
loop. There are also naming clashes now, and other problems.

</pre>
</blockquote>
<pre wrap="">Hmmm. I'm not sure I did screw up though. I think this template should
be invoked once per feature so you'd better be sure the code generated
is different for each feature...
</pre>
</blockquote>
<pre wrap=""><!---->
So far, the insert-template was called only once and the override
template did not work. Now with the bug fix, the override template
works, but the fix also changes the way the insert-tamplate is called,
because now it is called once per feature. But I agree with you that
this is probably how it should have been from the beginning. Thus, if
you tell me it will stay the way it is now, I'm happy with it and I'll
adapt my templates accordingly.

</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Thanks for your help!

Best,
Marc

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

--------------040802030203000800040007--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF JET Template Class.javajet - Problems with changes [message #420932 is a reply to message #420186] Wed, 16 July 2008 16:59 Go to previous messageGo to next message
Alessander Botti Benevides is currently offline Alessander Botti BenevidesFriend
Messages: 20
Registered: July 2009
Junior Member
Hi people,

I also use the EMF OCL integration explained in
http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html.
For years, I used the templates exactly as they were in the example file
of this tutorial (ocl-codegen.zip). But it stop working when I upgraded
to EMF 2.4.x :(
I have no idea of how to fix this templates for the new behavior of the
Class.javajet file that you're talking about, and I really need to use EMF
Validation With OCL. Please, can you help me?

Any help will be great,
Alessander Botti Benevides

Marc Moser wrote:

> Hi Ed,

> Comments below.

>>Marc,
>>
>>Comments beow.
>>
>>Marc Moser wrote:
>>> Hi,
>>>
>>> We use an EMF OCL integration as explained in
>>>
http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
>>> Unfortunately, code generation based on our adapted templates stopped
>>> working with build M7 and newer (we are using RC4 right now). But it
>>> worked fine up to and including build M6.
>>>
>>> I could identify the "root of this problem" in the EMF template
>>> Class.javajet. Prior to M7, lines 277-285 looked as follows:
>>>
>>> protected boolean <%=genFeature.getUncapName()%>ESet;
>>>
>>> <%}%>
>>> <%}%>
>>> <%}%>
>>> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
>>> fail="silent" %>
>>> <%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
>>> <%}%>
>>> <%if (isImplementation && genClass.hasOffsetCorrection() &&
>>> !genClass.getImplementedGenFeatures().isEmpty()) {%>
>>>
>>> Now in RC4, the corresponding lines 306-314 look as follows:
>>>
>>> protected boolean <%=genFeature.getUncapName()%>ESet;
>>>
>>> <%}%>
>>> <%}%>
>>> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
>>> fail="silent" %>
>>> <%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
>>> <%}%>
>>> <%}%>
>>> <%if (isImplementation && genClass.hasOffsetCorrection() &&
>>> !genClass.getImplementedGenFeatures().isEmpty()) {%>
>>>
>>> As you can see, one of the closing curly brace <%}%> was moved from
>>> before including declaredFieldGenFeature.insert.javajetinc to after
>>> including it.
>>>
>>> Is there a reason for this new behavior, or was this accidentally (ok,
>>> I am pretty sure there is a reason :-)?
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=230410
>>
>>> Also note that this closing
>>> brace actually closes a for-loop, so while before the insert template
>>> was inserted after the for loop, it is now inside the iteration of the
>>> foor loop.
>>>
>>Maybe I screwed it up...
>>> In our case this leads to several problems. We added e.g. a field to
>>> each class by simply declaring it in
>>> Class/declaredFieldGenFeature.insert.javajetinc Now, this doesn't work
>>> anymore because the field will be generated several times because
>>> Class/declaredFieldGenFeature.insert.javajetinc is called inside a
>>> loop. There are also naming clashes now, and other problems.
>>>
>>Hmmm. I'm not sure I did screw up though. I think this template should
>>be invoked once per feature so you'd better be sure the code generated
>>is different for each feature...

> So far, the insert-template was called only once and the override
> template did not work. Now with the bug fix, the override template
> works, but the fix also changes the way the insert-tamplate is called,
> because now it is called once per feature. But I agree with you that
> this is probably how it should have been from the beginning. Thus, if
> you tell me it will stay the way it is now, I'm happy with it and I'll
> adapt my templates accordingly.

>>> Thanks for your help!
>>>
>>> Best,
>>> Marc
>>>
Re: EMF JET Template Class.javajet - Problems with changes [message #420933 is a reply to message #420932] Wed, 16 July 2008 17:18 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33140
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------030403080102040909080700
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Alessander,

This insertion happens only once, instead of once per feature/operation
like all the other includes

<%@ include file="Class/insert.javajetinc" fail="silent" %>

Unfortunately it's at the end, which is okay, but not as nice.

I suppose a more hacky fix is to include a guard variable

<%@ jet package="org.eclipse.ocl.examples.codegen.templates.model"
imports="java.util.* org.eclipse.emf.codegen.ecore.genmodel.*
org.eclipse.emf.ecore.*" class="Class" version="$Id: index.html,v
1.1 2007/02/21 20:19:09 wbeaton Exp $" %>
<% final String oclNsURI =
"http://www.eclipse.org/ocl/examples/OCL"; %>
<%boolean once = false;%>
<%@ include file="Class.javajet"%>

and guard the part that's repeating.

We could add a proper "include-once insert in 2.5.


Alessander Botti Benevides wrote:
> Hi people,
>
> I also use the EMF OCL integration explained in
> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html.
>
> For years, I used the templates exactly as they were in the example
> file of this tutorial (ocl-codegen.zip). But it stop working when I
> upgraded to EMF 2.4.x :(
> I have no idea of how to fix this templates for the new behavior of
> the Class.javajet file that you're talking about, and I really need to
> use EMF Validation With OCL. Please, can you help me?
>
> Any help will be great,
> Alessander Botti Benevides
>
> Marc Moser wrote:
>
>> Hi Ed,
>
>> Comments below.
>
>>> Marc,
>>>
>>> Comments beow.
>>>
>>> Marc Moser wrote:
>>>> Hi,
>>>>
>>>> We use an EMF OCL integration as explained in
>>>>
> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
>
>>>> Unfortunately, code generation based on our adapted templates stopped
>>>> working with build M7 and newer (we are using RC4 right now). But it
>>>> worked fine up to and including build M6.
>>>>
>>>> I could identify the "root of this problem" in the EMF template
>>>> Class.javajet. Prior to M7, lines 277-285 looked as follows:
>>>>
>>>> protected boolean <%=genFeature.getUncapName()%>ESet;
>>>>
>>>> <%}%>
>>>> <%}%>
>>>> <%}%>
>>>> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
>>>> fail="silent" %>
>>>> <%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
>>>> <%}%>
>>>> <%if (isImplementation && genClass.hasOffsetCorrection() &&
>>>> !genClass.getImplementedGenFeatures().isEmpty()) {%>
>>>>
>>>> Now in RC4, the corresponding lines 306-314 look as follows:
>>>>
>>>> protected boolean <%=genFeature.getUncapName()%>ESet;
>>>>
>>>> <%}%>
>>>> <%}%>
>>>> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
>>>> fail="silent" %>
>>>> <%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
>>>> <%}%>
>>>> <%}%>
>>>> <%if (isImplementation && genClass.hasOffsetCorrection() &&
>>>> !genClass.getImplementedGenFeatures().isEmpty()) {%>
>>>>
>>>> As you can see, one of the closing curly brace <%}%> was moved from
>>>> before including declaredFieldGenFeature.insert.javajetinc to after
>>>> including it.
>>>>
>>>> Is there a reason for this new behavior, or was this accidentally (ok,
>>>> I am pretty sure there is a reason :-)?
>>>
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=230410
>>>
>>>> Also note that this closing
>>>> brace actually closes a for-loop, so while before the insert template
>>>> was inserted after the for loop, it is now inside the iteration of the
>>>> foor loop.
>>>>
>>> Maybe I screwed it up...
>>>> In our case this leads to several problems. We added e.g. a field to
>>>> each class by simply declaring it in
>>>> Class/declaredFieldGenFeature.insert.javajetinc Now, this doesn't work
>>>> anymore because the field will be generated several times because
>>>> Class/declaredFieldGenFeature.insert.javajetinc is called inside a
>>>> loop. There are also naming clashes now, and other problems.
>>>>
>>> Hmmm. I'm not sure I did screw up though. I think this template
>>> should be invoked once per feature so you'd better be sure the code
>>> generated is different for each feature...
>
>> So far, the insert-template was called only once and the override
>> template did not work. Now with the bug fix, the override template
>> works, but the fix also changes the way the insert-tamplate is called,
>> because now it is called once per feature. But I agree with you that
>> this is probably how it should have been from the beginning. Thus, if
>> you tell me it will stay the way it is now, I'm happy with it and I'll
>> adapt my templates accordingly.
>
>>>> Thanks for your help!
>>>>
>>>> Best,
>>>> Marc
>>>>
>

--------------030403080102040909080700
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Alessander,<br>
<br>
This insertion happens only once, instead of once per feature/operation
like all the other includes<br>
<blockquote>&lt;%@ include file="Class/insert.javajetinc" fail="silent"
%&gt;<br>
</blockquote>
Unfortunately it's at the end, which is okay, but not as nice.<br>
<br>
I suppose a more hacky fix is to include a guard variable<br>
<blockquote>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF JET Template Class.javajet - Problems with changes [message #420937 is a reply to message #420933] Wed, 16 July 2008 18:44 Go to previous messageGo to next message
Alessander Botti Benevides is currently offline Alessander Botti BenevidesFriend
Messages: 20
Registered: July 2009
Junior Member
Thanks Ed,

I replaced the code <%@ include file="Class.javajet"%> with <%@ include
file="Class/insert.javajetinc" fail="silent" %> in the Class.javajet
provided by the tutorial, and <%@ include file="../Header.javajetinc" %>
with <%@ include file="../Header.javajetinc" fail="silent" %> int the
ValidatorClass.javajet. But it didn't worked, the codes for many classes
still aren't generated:
* Company.java, Department.java, Employee.java (in
/org.eclipse.ocl.examples.employee/src/org/eclipse/ocl/examp les/employee/)
* CompanyImpl.java, DepartmentImpl.java, EmployeeImpl.java (in
/org.eclipse.ocl.examples.employee/src/org/eclipse/ocl/examp les/employee/impl/)

These classes are all empty :(
I think it's not that simple, but I don't know what to do...

Thanks for your help!
Alessander Botti Benevides

Ed Merks wrote:

> Alessander,

> This insertion happens only once, instead of once per feature/operation
> like all the other includes

> <%@ include file="Class/insert.javajetinc" fail="silent" %>

> Unfortunately it's at the end, which is okay, but not as nice.

> I suppose a more hacky fix is to include a guard variable

> <%@ jet package="org.eclipse.ocl.examples.codegen.templates.model"
> imports="java.util.* org.eclipse.emf.codegen.ecore.genmodel.*
> org.eclipse.emf.ecore.*" class="Class" version="$Id: index.html,v
> 1.1 2007/02/21 20:19:09 wbeaton Exp $" %>
> <% final String oclNsURI =
> "http://www.eclipse.org/ocl/examples/OCL"; %>
> <%boolean once = false;%>
> <%@ include file="Class.javajet"%>

> and guard the part that's repeating.

> We could add a proper "include-once insert in 2.5.


> Alessander Botti Benevides wrote:
>> Hi people,
>>
>> I also use the EMF OCL integration explained in
>>
http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html.
>>
>> For years, I used the templates exactly as they were in the example
>> file of this tutorial (ocl-codegen.zip). But it stop working when I
>> upgraded to EMF 2.4.x :(
>> I have no idea of how to fix this templates for the new behavior of
>> the Class.javajet file that you're talking about, and I really need to
>> use EMF Validation With OCL. Please, can you help me?
>>
>> Any help will be great,
>> Alessander Botti Benevides
>>
>> Marc Moser wrote:
>>
>>> Hi Ed,
>>
>>> Comments below.
>>
>>>> Marc,
>>>>
>>>> Comments beow.
>>>>
>>>> Marc Moser wrote:
>>>>> Hi,
>>>>>
>>>>> We use an EMF OCL integration as explained in
>>>>>
>>
http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
>>
>>>>> Unfortunately, code generation based on our adapted templates stopped
>>>>> working with build M7 and newer (we are using RC4 right now). But it
>>>>> worked fine up to and including build M6.
>>>>>
>>>>> I could identify the "root of this problem" in the EMF template
>>>>> Class.javajet. Prior to M7, lines 277-285 looked as follows:
>>>>>
>>>>> protected boolean <%=genFeature.getUncapName()%>ESet;
>>>>>
>>>>> <%}%>
>>>>> <%}%>
>>>>> <%}%>
>>>>> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
>>>>> fail="silent" %>
>>>>> <%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
>>>>> <%}%>
>>>>> <%if (isImplementation && genClass.hasOffsetCorrection() &&
>>>>> !genClass.getImplementedGenFeatures().isEmpty()) {%>
>>>>>
>>>>> Now in RC4, the corresponding lines 306-314 look as follows:
>>>>>
>>>>> protected boolean <%=genFeature.getUncapName()%>ESet;
>>>>>
>>>>> <%}%>
>>>>> <%}%>
>>>>> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
>>>>> fail="silent" %>
>>>>> <%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
>>>>> <%}%>
>>>>> <%}%>
>>>>> <%if (isImplementation && genClass.hasOffsetCorrection() &&
>>>>> !genClass.getImplementedGenFeatures().isEmpty()) {%>
>>>>>
>>>>> As you can see, one of the closing curly brace <%}%> was moved from
>>>>> before including declaredFieldGenFeature.insert.javajetinc to after
>>>>> including it.
>>>>>
>>>>> Is there a reason for this new behavior, or was this accidentally (ok,
>>>>> I am pretty sure there is a reason :-)?
>>>>
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=230410
>>>>
>>>>> Also note that this closing
>>>>> brace actually closes a for-loop, so while before the insert template
>>>>> was inserted after the for loop, it is now inside the iteration of the
>>>>> foor loop.
>>>>>
>>>> Maybe I screwed it up...
>>>>> In our case this leads to several problems. We added e.g. a field to
>>>>> each class by simply declaring it in
>>>>> Class/declaredFieldGenFeature.insert.javajetinc Now, this doesn't work
>>>>> anymore because the field will be generated several times because
>>>>> Class/declaredFieldGenFeature.insert.javajetinc is called inside a
>>>>> loop. There are also naming clashes now, and other problems.
>>>>>
>>>> Hmmm. I'm not sure I did screw up though. I think this template
>>>> should be invoked once per feature so you'd better be sure the code
>>>> generated is different for each feature...
>>
>>> So far, the insert-template was called only once and the override
>>> template did not work. Now with the bug fix, the override template
>>> works, but the fix also changes the way the insert-tamplate is called,
>>> because now it is called once per feature. But I agree with you that
>>> this is probably how it should have been from the beginning. Thus, if
>>> you tell me it will stay the way it is now, I'm happy with it and I'll
>>> adapt my templates accordingly.
>>
>>>>> Thanks for your help!
>>>>>
>>>>> Best,
>>>>> Marc
>>>>>
>>
Re: EMF JET Template Class.javajet - Problems with changes [message #420939 is a reply to message #420937] Wed, 16 July 2008 18:54 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33140
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------020708050906050003060606
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Alessander,

Comments below.

Alessander Botti Benevides wrote:
> Thanks Ed,
>
> I replaced the code <%@ include file="Class.javajet"%> with <%@
> include file="Class/insert.javajetinc" fail="silent" %> in the
> Class.javajet provided by the tutorial, and <%@ include
> file="../Header.javajetinc" %> with <%@ include
> file="../Header.javajetinc" fail="silent" %> int the
> ValidatorClass.javajet. But it didn't worked, the codes for many
> classes still aren't generated:
> * Company.java, Department.java, Employee.java (in
> /org.eclipse.ocl.examples.employee/src/org/eclipse/ocl/examp les/employee/)
>
> * CompanyImpl.java, DepartmentImpl.java, EmployeeImpl.java (in
> /org.eclipse.ocl.examples.employee/src/org/eclipse/ocl/examp les/employee/impl/)
>
>
> These classes are all empty :(
That's not what I showed though. I had two possible approaches. I.e.,
override to exploit this

<%@ include file="Class/insert.javajetinc" fail="silent" %>

instead of

<%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
fail="silent" %>

by moving/renaming Class/declaredFieldGenFeature.insert.javajetinc to
Class/insert.javajetinc. This will result in the contents being
generated as the end of the Impl class (for new classes; you can move
them where ever you want by hand.

The other suggestion was to use exactly the Class.javajet you had before
but with the "*once*" flag added.

<%@ jet package="org.eclipse.ocl.examples.codegen.templates.model"
imports="java.util.* org.eclipse.emf.codegen.ecore.genmodel.*
org.eclipse.emf.ecore.*" class="Class" version="$Id: index.html,v
1.1 2007/02/21 20:19:09 wbeaton Exp $" %>
<% final String oclNsURI =
"http://www.eclipse.org/ocl/examples/OCL"; %>
*<%boolean once = false;%>*
<%@ include file="Class.javajet"%>

You could then change Class/declaredFieldGenFeature.insert.javajetinc to
add a guard such that the body of what it generates is only done once.
I.e., if (!once) { once = true; <whatever was there before> }.
> I think it's not that simple, but I don't know what to do...
>
> Thanks for your help!
> Alessander Botti Benevides
>
> Ed Merks wrote:
>
>> Alessander,
>
>> This insertion happens only once, instead of once per
>> feature/operation like all the other includes
>
>> <%@ include file="Class/insert.javajetinc" fail="silent" %>
>
>> Unfortunately it's at the end, which is okay, but not as nice.
>
>> I suppose a more hacky fix is to include a guard variable
>
>> <%@ jet package="org.eclipse.ocl.examples.codegen.templates.model"
>> imports="java.util.* org.eclipse.emf.codegen.ecore.genmodel.*
>> org.eclipse.emf.ecore.*" class="Class" version="$Id: index.html,v
>> 1.1 2007/02/21 20:19:09 wbeaton Exp $" %>
>> <% final String oclNsURI =
>> "http://www.eclipse.org/ocl/examples/OCL"; %>
>> <%boolean once = false;%>
>> <%@ include file="Class.javajet"%>
>
>> and guard the part that's repeating.
>
>> We could add a proper "include-once insert in 2.5.
>
>
>> Alessander Botti Benevides wrote:
>>> Hi people,
>>>
>>> I also use the EMF OCL integration explained in
>>>
> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html.
>
>>>
>>> For years, I used the templates exactly as they were in the example
>>> file of this tutorial (ocl-codegen.zip). But it stop working when I
>>> upgraded to EMF 2.4.x :(
>>> I have no idea of how to fix this templates for the new behavior of
>>> the Class.javajet file that you're talking about, and I really need
>>> to use EMF Validation With OCL. Please, can you help me?
>>>
>>> Any help will be great,
>>> Alessander Botti Benevides
>>>
>>> Marc Moser wrote:
>>>
>>>> Hi Ed,
>>>
>>>> Comments below.
>>>
>>>>> Marc,
>>>>>
>>>>> Comments beow.
>>>>>
>>>>> Marc Moser wrote:
>>>>>> Hi,
>>>>>>
>>>>>> We use an EMF OCL integration as explained in
>>>>>>
>>>
> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
>
>>>
>>>>>> Unfortunately, code generation based on our adapted templates
>>>>>> stopped
>>>>>> working with build M7 and newer (we are using RC4 right now). But it
>>>>>> worked fine up to and including build M6.
>>>>>>
>>>>>> I could identify the "root of this problem" in the EMF template
>>>>>> Class.javajet. Prior to M7, lines 277-285 looked as follows:
>>>>>>
>>>>>> protected boolean <%=genFeature.getUncapName()%>ESet;
>>>>>>
>>>>>> <%}%>
>>>>>> <%}%>
>>>>>> <%}%>
>>>>>> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
>>>>>> fail="silent" %>
>>>>>> <%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
>>>>>> <%}%>
>>>>>> <%if (isImplementation && genClass.hasOffsetCorrection() &&
>>>>>> !genClass.getImplementedGenFeatures().isEmpty()) {%>
>>>>>>
>>>>>> Now in RC4, the corresponding lines 306-314 look as follows:
>>>>>>
>>>>>> protected boolean <%=genFeature.getUncapName()%>ESet;
>>>>>>
>>>>>> <%}%>
>>>>>> <%}%>
>>>>>> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
>>>>>> fail="silent" %>
>>>>>> <%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
>>>>>> <%}%>
>>>>>> <%}%>
>>>>>> <%if (isImplementation && genClass.hasOffsetCorrection() &&
>>>>>> !genClass.getImplementedGenFeatures().isEmpty()) {%>
>>>>>>
>>>>>> As you can see, one of the closing curly brace <%}%> was moved from
>>>>>> before including declaredFieldGenFeature.insert.javajetinc to after
>>>>>> including it.
>>>>>>
>>>>>> Is there a reason for this new behavior, or was this accidentally
>>>>>> (ok,
>>>>>> I am pretty sure there is a reason :-)?
>>>>>
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=230410
>>>>>
>>>>>> Also note that this closing
>>>>>> brace actually closes a for-loop, so while before the insert
>>>>>> template
>>>>>> was inserted after the for loop, it is now inside the iteration
>>>>>> of the
>>>>>> foor loop.
>>>>>>
>>>>> Maybe I screwed it up...
>>>>>> In our case this leads to several problems. We added e.g. a field to
>>>>>> each class by simply declaring it in
>>>>>> Class/declaredFieldGenFeature.insert.javajetinc Now, this doesn't
>>>>>> work
>>>>>> anymore because the field will be generated several times because
>>>>>> Class/declaredFieldGenFeature.insert.javajetinc is called inside a
>>>>>> loop. There are also naming clashes now, and other problems.
>>>>>>
>>>>> Hmmm. I'm not sure I did screw up though. I think this template
>>>>> should be invoked once per feature so you'd better be sure the
>>>>> code generated is different for each feature...
>>>
>>>> So far, the insert-template was called only once and the override
>>>> template did not work. Now with the bug fix, the override template
>>>> works, but the fix also changes the way the insert-tamplate is called,
>>>> because now it is called once per feature. But I agree with you that
>>>> this is probably how it should have been from the beginning. Thus, if
>>>> you tell me it will stay the way it is now, I'm happy with it and I'll
>>>> adapt my templates accordingly.
>>>
>>>>>> Thanks for your help!
>>>>>>
>>>>>> Best,
>>>>>> Marc
>>>>>>
>>>
>
>

--------------020708050906050003060606
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Alessander,<br>
<br>
Comments below.<br>
<br>
Alessander Botti Benevides wrote:
<blockquote
cite="mid:e5d5b16b8488975fb055482abeece33d$1@www.eclipse.org"
type="cite">Thanks Ed,
<br>
<br>
I replaced the code &lt;%@ include file="Class.javajet"%&gt; with
&lt;%@ include file="Class/insert.javajetinc" fail="silent" %&gt; in
the Class.javajet provided by the tutorial, and &lt;%@ include
file="../Header.javajetinc" %&gt; with &lt;%@ include
file="../Header.javajetinc" fail="silent" %&gt; int the
ValidatorClass.javajet. But it didn't worked, the codes for many
classes still aren't generated:
<br>
* Company.java, Department.java, Employee.java (in
/org.eclipse.ocl.examples.employee/src/org/eclipse/ocl/examp les/employee/)
<br>
* CompanyImpl.java, DepartmentImpl.java, EmployeeImpl.java (in
/org.eclipse.ocl.examples.employee/src/org/eclipse/ocl/examp les/employee/impl/)
<br>
<br>
These classes are all empty :(
<br>
</blockquote>
That's not what I showed though.


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF JET Template Class.javajet - Problems with changes [message #420942 is a reply to message #420939] Wed, 16 July 2008 20:11 Go to previous messageGo to next message
Alessander Botti Benevides is currently offline Alessander Botti BenevidesFriend
Messages: 20
Registered: July 2009
Junior Member
Ed, I'll post my results below.

Ed Merks wrote:

> Alessander,

> Comments below.

> Alessander Botti Benevides wrote:
>> Thanks Ed,
>>
>> I replaced the code <%@ include file="Class.javajet"%> with <%@
>> include file="Class/insert.javajetinc" fail="silent" %> in the
>> Class.javajet provided by the tutorial, and <%@ include
>> file="../Header.javajetinc" %> with <%@ include
>> file="../Header.javajetinc" fail="silent" %> int the
>> ValidatorClass.javajet. But it didn't worked, the codes for many
>> classes still aren't generated:
>> * Company.java, Department.java, Employee.java (in
>> /org.eclipse.ocl.examples.employee/src/org/eclipse/ocl/examp les/employee/)
>>
>> * CompanyImpl.java, DepartmentImpl.java, EmployeeImpl.java (in
>>
/org.eclipse.ocl.examples.employee/src/org/eclipse/ocl/examp les/employee/impl/)
>>
>>
>> These classes are all empty :(
> That's not what I showed though. I had two possible approaches. I.e.,
> override to exploit this

> <%@ include file="Class/insert.javajetinc" fail="silent" %>

> instead of

> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
> fail="silent" %>

> by moving/renaming Class/declaredFieldGenFeature.insert.javajetinc to
> Class/insert.javajetinc. This will result in the contents being
> generated as the end of the Impl class (for new classes; you can move
> them where ever you want by hand.

I renamed Class/declaredFieldGenFeature.insert.javajetinc to
Class/insert.javajetinc and replaced <%@ include file="Class.javajet"%>
with <%@ include file="Class/insert.javajetinc" fail="silent" %> in the
Class.javajet. But I've got the following errors:

Description: genClass cannot be resolved
genModel cannot be resolved
isImplementation cannot be resolved
On element: Class.java
In folder:
JETEmitters/src/org/eclipse/ocl/examples/codegen/templates/m odel

> The other suggestion was to use exactly the Class.javajet you had before
> but with the "*once*" flag added.

> <%@ jet package="org.eclipse.ocl.examples.codegen.templates.model"
> imports="java.util.* org.eclipse.emf.codegen.ecore.genmodel.*
> org.eclipse.emf.ecore.*" class="Class" version="$Id: index.html,v
> 1.1 2007/02/21 20:19:09 wbeaton Exp $" %>
> <% final String oclNsURI =
> "http://www.eclipse.org/ocl/examples/OCL"; %>
> *<%boolean once = false;%>*
> <%@ include file="Class.javajet"%>

> You could then change Class/declaredFieldGenFeature.insert.javajetinc to
> add a guard such that the body of what it generates is only done once.
> I.e., if (!once) { once = true; <whatever was there before> }.

I also did this and had the error:

Description: Duplicate local variable genFeature
On element: Class.java
In folder:
JETEmitters/src/org/eclipse/ocl/examples/codegen/templates/m odel

Is there a less painful way to get EMF Validation, just like GMF
Validation?

Thanks,
Alessander

>> I think it's not that simple, but I don't know what to do...
>>
>> Thanks for your help!
>> Alessander Botti Benevides
>>
>> Ed Merks wrote:
>>
>>> Alessander,
>>
>>> This insertion happens only once, instead of once per
>>> feature/operation like all the other includes
>>
>>> <%@ include file="Class/insert.javajetinc" fail="silent" %>
>>
>>> Unfortunately it's at the end, which is okay, but not as nice.
>>
>>> I suppose a more hacky fix is to include a guard variable
>>
>>> <%@ jet package="org.eclipse.ocl.examples.codegen.templates.model"
>>> imports="java.util.* org.eclipse.emf.codegen.ecore.genmodel.*
>>> org.eclipse.emf.ecore.*" class="Class" version="$Id: index.html,v
>>> 1.1 2007/02/21 20:19:09 wbeaton Exp $" %>
>>> <% final String oclNsURI =
>>> "http://www.eclipse.org/ocl/examples/OCL"; %>
>>> <%boolean once = false;%>
>>> <%@ include file="Class.javajet"%>
>>
>>> and guard the part that's repeating.
>>
>>> We could add a proper "include-once insert in 2.5.
>>
>>
>>> Alessander Botti Benevides wrote:
>>>> Hi people,
>>>>
>>>> I also use the EMF OCL integration explained in
>>>>
>>
http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html.
>>
>>>>
>>>> For years, I used the templates exactly as they were in the example
>>>> file of this tutorial (ocl-codegen.zip). But it stop working when I
>>>> upgraded to EMF 2.4.x :(
>>>> I have no idea of how to fix this templates for the new behavior of
>>>> the Class.javajet file that you're talking about, and I really need
>>>> to use EMF Validation With OCL. Please, can you help me?
>>>>
>>>> Any help will be great,
>>>> Alessander Botti Benevides
>>>>
>>>> Marc Moser wrote:
>>>>
>>>>> Hi Ed,
>>>>
>>>>> Comments below.
>>>>
>>>>>> Marc,
>>>>>>
>>>>>> Comments beow.
>>>>>>
>>>>>> Marc Moser wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> We use an EMF OCL integration as explained in
>>>>>>>
>>>>
>>
http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
>>
>>>>
>>>>>>> Unfortunately, code generation based on our adapted templates
>>>>>>> stopped
>>>>>>> working with build M7 and newer (we are using RC4 right now). But it
>>>>>>> worked fine up to and including build M6.
>>>>>>>
>>>>>>> I could identify the "root of this problem" in the EMF template
>>>>>>> Class.javajet. Prior to M7, lines 277-285 looked as follows:
>>>>>>>
>>>>>>> protected boolean <%=genFeature.getUncapName()%>ESet;
>>>>>>>
>>>>>>> <%}%>
>>>>>>> <%}%>
>>>>>>> <%}%>
>>>>>>> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
>>>>>>> fail="silent" %>
>>>>>>> <%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
>>>>>>> <%}%>
>>>>>>> <%if (isImplementation && genClass.hasOffsetCorrection() &&
>>>>>>> !genClass.getImplementedGenFeatures().isEmpty()) {%>
>>>>>>>
>>>>>>> Now in RC4, the corresponding lines 306-314 look as follows:
>>>>>>>
>>>>>>> protected boolean <%=genFeature.getUncapName()%>ESet;
>>>>>>>
>>>>>>> <%}%>
>>>>>>> <%}%>
>>>>>>> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
>>>>>>> fail="silent" %>
>>>>>>> <%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
>>>>>>> <%}%>
>>>>>>> <%}%>
>>>>>>> <%if (isImplementation && genClass.hasOffsetCorrection() &&
>>>>>>> !genClass.getImplementedGenFeatures().isEmpty()) {%>
>>>>>>>
>>>>>>> As you can see, one of the closing curly brace <%}%> was moved from
>>>>>>> before including declaredFieldGenFeature.insert.javajetinc to after
>>>>>>> including it.
>>>>>>>
>>>>>>> Is there a reason for this new behavior, or was this accidentally
>>>>>>> (ok,
>>>>>>> I am pretty sure there is a reason :-)?
>>>>>>
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=230410
>>>>>>
>>>>>>> Also note that this closing
>>>>>>> brace actually closes a for-loop, so while before the insert
>>>>>>> template
>>>>>>> was inserted after the for loop, it is now inside the iteration
>>>>>>> of the
>>>>>>> foor loop.
>>>>>>>
>>>>>> Maybe I screwed it up...
>>>>>>> In our case this leads to several problems. We added e.g. a field to
>>>>>>> each class by simply declaring it in
>>>>>>> Class/declaredFieldGenFeature.insert.javajetinc Now, this doesn't
>>>>>>> work
>>>>>>> anymore because the field will be generated several times because
>>>>>>> Class/declaredFieldGenFeature.insert.javajetinc is called inside a
>>>>>>> loop. There are also naming clashes now, and other problems.
>>>>>>>
>>>>>> Hmmm. I'm not sure I did screw up though. I think this template
>>>>>> should be invoked once per feature so you'd better be sure the
>>>>>> code generated is different for each feature...
>>>>
>>>>> So far, the insert-template was called only once and the override
>>>>> template did not work. Now with the bug fix, the override template
>>>>> works, but the fix also changes the way the insert-tamplate is called,
>>>>> because now it is called once per feature. But I agree with you that
>>>>> this is probably how it should have been from the beginning. Thus, if
>>>>> you tell me it will stay the way it is now, I'm happy with it and I'll
>>>>> adapt my templates accordingly.
>>>>
>>>>>>> Thanks for your help!
>>>>>>>
>>>>>>> Best,
>>>>>>> Marc
>>>>>>>
>>>>
>>
>>
Re: EMF JET Template Class.javajet - Problems with changes [message #420943 is a reply to message #420942] Wed, 16 July 2008 20:22 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33140
Registered: July 2009
Senior Member
Alessander,

Comments below.

Alessander Botti Benevides wrote:
> Ed, I'll post my results below.
>
> Ed Merks wrote:
>
>> Alessander,
>
>> Comments below.
>
>> Alessander Botti Benevides wrote:
>>> Thanks Ed,
>>>
>>> I replaced the code <%@ include file="Class.javajet"%> with <%@
>>> include file="Class/insert.javajetinc" fail="silent" %> in the
>>> Class.javajet provided by the tutorial, and <%@ include
>>> file="../Header.javajetinc" %> with <%@ include
>>> file="../Header.javajetinc" fail="silent" %> int the
>>> ValidatorClass.javajet. But it didn't worked, the codes for many
>>> classes still aren't generated:
>>> * Company.java, Department.java, Employee.java (in
>>> /org.eclipse.ocl.examples.employee/src/org/eclipse/ocl/examp les/employee/)
>>>
>>> * CompanyImpl.java, DepartmentImpl.java, EmployeeImpl.java (in
> /org.eclipse.ocl.examples.employee/src/org/eclipse/ocl/examp les/employee/impl/)
>
>>>
>>>
>>> These classes are all empty :(
>> That's not what I showed though. I had two possible approaches.
>> I.e., override to exploit this
>
>> <%@ include file="Class/insert.javajetinc" fail="silent" %>
>
>> instead of
>
>> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
>> fail="silent" %>
>
>> by moving/renaming Class/declaredFieldGenFeature.insert.javajetinc to
>> Class/insert.javajetinc. This will result in the contents being
>> generated as the end of the Impl class (for new classes; you can move
>> them where ever you want by hand.
>
> I renamed Class/declaredFieldGenFeature.insert.javajetinc to
> Class/insert.javajetinc and replaced <%@ include
> file="Class.javajet"%> with <%@ include file="Class/insert.javajetinc"
> fail="silent" %> in the Class.javajet. But I've got the following errors:
No don't replace anything. Leave it alone. Only rename the the file no
"and" part. Leave Class.javajet exactly how it was.
>
> Description: genClass cannot be resolved
> genModel cannot be resolved
> isImplementation cannot be resolved
> On element: Class.java
> In folder:
> JETEmitters/src/org/eclipse/ocl/examples/codegen/templates/m odel
>> The other suggestion was to use exactly the Class.javajet you had
>> before but with the "*once*" flag added.
>
>> <%@ jet package="org.eclipse.ocl.examples.codegen.templates.model"
>> imports="java.util.* org.eclipse.emf.codegen.ecore.genmodel.*
>> org.eclipse.emf.ecore.*" class="Class" version="$Id: index.html,v
>> 1.1 2007/02/21 20:19:09 wbeaton Exp $" %>
>> <% final String oclNsURI =
>> "http://www.eclipse.org/ocl/examples/OCL"; %>
>> *<%boolean once = false;%>*
>> <%@ include file="Class.javajet"%>
>
>> You could then change Class/declaredFieldGenFeature.insert.javajetinc
>> to add a guard such that the body of what it generates is only done
>> once. I.e., if (!once) { once = true; <whatever was there before> }.
>
> I also did this and had the error:
>
> Description: Duplicate local variable genFeature
> On element: Class.java
> In folder:
> JETEmitters/src/org/eclipse/ocl/examples/codegen/templates/m odel
You're sure there aren't changes you didn't tell me about. (For example,
leaving the results of the previous changes in place so you have both a
Class/declaredFieldGenFeature.insert.javajetinc and a
Class/insert.javajetinc?) After all, how does adding the guard
introduce duplicates? Clearly there's something additional you've done
other than declare guard variable and use guard variable...
>
> Is there a less painful way to get EMF Validation, just like GMF
> Validation?
>
> Thanks,
> Alessander
>
>>> I think it's not that simple, but I don't know what to do...
>>>
>>> Thanks for your help!
>>> Alessander Botti Benevides
>>>
>>> Ed Merks wrote:
>>>
>>>> Alessander,
>>>
>>>> This insertion happens only once, instead of once per
>>>> feature/operation like all the other includes
>>>
>>>> <%@ include file="Class/insert.javajetinc" fail="silent" %>
>>>
>>>> Unfortunately it's at the end, which is okay, but not as nice.
>>>
>>>> I suppose a more hacky fix is to include a guard variable
>>>
>>>> <%@ jet
>>>> package="org.eclipse.ocl.examples.codegen.templates.model"
>>>> imports="java.util.* org.eclipse.emf.codegen.ecore.genmodel.*
>>>> org.eclipse.emf.ecore.*" class="Class" version="$Id: index.html,v
>>>> 1.1 2007/02/21 20:19:09 wbeaton Exp $" %>
>>>> <% final String oclNsURI =
>>>> "http://www.eclipse.org/ocl/examples/OCL"; %>
>>>> <%boolean once = false;%>
>>>> <%@ include file="Class.javajet"%>
>>>
>>>> and guard the part that's repeating.
>>>
>>>> We could add a proper "include-once insert in 2.5.
>>>
>>>
>>>> Alessander Botti Benevides wrote:
>>>>> Hi people,
>>>>>
>>>>> I also use the EMF OCL integration explained in
>>>>>
>>>
> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html.
>
>>>
>>>>>
>>>>> For years, I used the templates exactly as they were in the
>>>>> example file of this tutorial (ocl-codegen.zip). But it stop
>>>>> working when I upgraded to EMF 2.4.x :(
>>>>> I have no idea of how to fix this templates for the new behavior
>>>>> of the Class.javajet file that you're talking about, and I really
>>>>> need to use EMF Validation With OCL. Please, can you help me?
>>>>>
>>>>> Any help will be great,
>>>>> Alessander Botti Benevides
>>>>>
>>>>> Marc Moser wrote:
>>>>>
>>>>>> Hi Ed,
>>>>>
>>>>>> Comments below.
>>>>>
>>>>>>> Marc,
>>>>>>>
>>>>>>> Comments beow.
>>>>>>>
>>>>>>> Marc Moser wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> We use an EMF OCL integration as explained in
>>>>>>>>
>>>>>
>>>
> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
>
>>>
>>>>>
>>>>>>>> Unfortunately, code generation based on our adapted templates
>>>>>>>> stopped
>>>>>>>> working with build M7 and newer (we are using RC4 right now).
>>>>>>>> But it
>>>>>>>> worked fine up to and including build M6.
>>>>>>>>
>>>>>>>> I could identify the "root of this problem" in the EMF template
>>>>>>>> Class.javajet. Prior to M7, lines 277-285 looked as follows:
>>>>>>>>
>>>>>>>> protected boolean <%=genFeature.getUncapName()%>ESet;
>>>>>>>>
>>>>>>>> <%}%>
>>>>>>>> <%}%>
>>>>>>>> <%}%>
>>>>>>>> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
>>>>>>>> fail="silent" %>
>>>>>>>> <%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
>>>>>>>> <%}%>
>>>>>>>> <%if (isImplementation && genClass.hasOffsetCorrection() &&
>>>>>>>> !genClass.getImplementedGenFeatures().isEmpty()) {%>
>>>>>>>>
>>>>>>>> Now in RC4, the corresponding lines 306-314 look as follows:
>>>>>>>>
>>>>>>>> protected boolean <%=genFeature.getUncapName()%>ESet;
>>>>>>>>
>>>>>>>> <%}%>
>>>>>>>> <%}%>
>>>>>>>> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
>>>>>>>> fail="silent" %>
>>>>>>>> <%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
>>>>>>>> <%}%>
>>>>>>>> <%}%>
>>>>>>>> <%if (isImplementation && genClass.hasOffsetCorrection() &&
>>>>>>>> !genClass.getImplementedGenFeatures().isEmpty()) {%>
>>>>>>>>
>>>>>>>> As you can see, one of the closing curly brace <%}%> was moved
>>>>>>>> from
>>>>>>>> before including declaredFieldGenFeature.insert.javajetinc to
>>>>>>>> after
>>>>>>>> including it.
>>>>>>>>
>>>>>>>> Is there a reason for this new behavior, or was this
>>>>>>>> accidentally (ok,
>>>>>>>> I am pretty sure there is a reason :-)?
>>>>>>>
>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=230410
>>>>>>>
>>>>>>>> Also note that this closing
>>>>>>>> brace actually closes a for-loop, so while before the insert
>>>>>>>> template
>>>>>>>> was inserted after the for loop, it is now inside the iteration
>>>>>>>> of the
>>>>>>>> foor loop.
>>>>>>>>
>>>>>>> Maybe I screwed it up...
>>>>>>>> In our case this leads to several problems. We added e.g. a
>>>>>>>> field to
>>>>>>>> each class by simply declaring it in
>>>>>>>> Class/declaredFieldGenFeature.insert.javajetinc Now, this
>>>>>>>> doesn't work
>>>>>>>> anymore because the field will be generated several times because
>>>>>>>> Class/declaredFieldGenFeature.insert.javajetinc is called inside a
>>>>>>>> loop. There are also naming clashes now, and other problems.
>>>>>>>>
>>>>>>> Hmmm. I'm not sure I did screw up though. I think this
>>>>>>> template should be invoked once per feature so you'd better be
>>>>>>> sure the code generated is different for each feature...
>>>>>
>>>>>> So far, the insert-template was called only once and the override
>>>>>> template did not work. Now with the bug fix, the override template
>>>>>> works, but the fix also changes the way the insert-tamplate is
>>>>>> called,
>>>>>> because now it is called once per feature. But I agree with you that
>>>>>> this is probably how it should have been from the beginning.
>>>>>> Thus, if
>>>>>> you tell me it will stay the way it is now, I'm happy with it and
>>>>>> I'll
>>>>>> adapt my templates accordingly.
>>>>>
>>>>>>>> Thanks for your help!
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> Marc
>>>>>>>>
>>>>>
>>>
>>>
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: EMF JET Template Class.javajet - Problems with changes [message #420948 is a reply to message #420943] Thu, 17 July 2008 00:23 Go to previous message
Alessander Botti Benevides is currently offline Alessander Botti BenevidesFriend
Messages: 20
Registered: July 2009
Junior Member
Thank you very very much for your help!

I only renamed Class/declaredFieldGenFeature.insert.javajetinc to
Class/insert.javajetinc and it works!

You saved my Eclipse plugin project (OntoUML Editor at Google Code)!
I use a lot of GMF Audit Containers and Rules to model ontology
constraints, but I also need EMF OCL integration to create derivations
rules for EAttributes and EReferences, and to model EOperations bodies
with OCL.
Unfortunatelly, I lost a lot of time because my workspace broke. I just
had to erase .metada, but I didn't notice that the problem was the
workspace...

So, thank you again!
Alessander Botti Benevides

Ed Merks wrote:

> Alessander,

> Comments below.

> Alessander Botti Benevides wrote:
>> Ed, I'll post my results below.
>>
>> Ed Merks wrote:
>>
>>> Alessander,
>>
>>> Comments below.
>>
>>> Alessander Botti Benevides wrote:
>>>> Thanks Ed,
>>>>
>>>> I replaced the code <%@ include file="Class.javajet"%> with <%@
>>>> include file="Class/insert.javajetinc" fail="silent" %> in the
>>>> Class.javajet provided by the tutorial, and <%@ include
>>>> file="../Header.javajetinc" %> with <%@ include
>>>> file="../Header.javajetinc" fail="silent" %> int the
>>>> ValidatorClass.javajet. But it didn't worked, the codes for many
>>>> classes still aren't generated:
>>>> * Company.java, Department.java, Employee.java (in
>>>>
/org.eclipse.ocl.examples.employee/src/org/eclipse/ocl/examp les/employee/)
>>>>
>>>> * CompanyImpl.java, DepartmentImpl.java, EmployeeImpl.java (in
>>
/org.eclipse.ocl.examples.employee/src/org/eclipse/ocl/examp les/employee/impl/)
>>
>>>>
>>>>
>>>> These classes are all empty :(
>>> That's not what I showed though. I had two possible approaches.
>>> I.e., override to exploit this
>>
>>> <%@ include file="Class/insert.javajetinc" fail="silent" %>
>>
>>> instead of
>>
>>> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
>>> fail="silent" %>
>>
>>> by moving/renaming Class/declaredFieldGenFeature.insert.javajetinc to
>>> Class/insert.javajetinc. This will result in the contents being
>>> generated as the end of the Impl class (for new classes; you can move
>>> them where ever you want by hand.
>>
>> I renamed Class/declaredFieldGenFeature.insert.javajetinc to
>> Class/insert.javajetinc and replaced <%@ include
>> file="Class.javajet"%> with <%@ include file="Class/insert.javajetinc"
>> fail="silent" %> in the Class.javajet. But I've got the following errors:
> No don't replace anything. Leave it alone. Only rename the the file no
> "and" part. Leave Class.javajet exactly how it was.
>>
>> Description: genClass cannot be resolved
>> genModel cannot be resolved
>> isImplementation cannot be resolved
>> On element: Class.java
>> In folder:
>> JETEmitters/src/org/eclipse/ocl/examples/codegen/templates/m odel
>>> The other suggestion was to use exactly the Class.javajet you had
>>> before but with the "*once*" flag added.
>>
>>> <%@ jet package="org.eclipse.ocl.examples.codegen.templates.model"
>>> imports="java.util.* org.eclipse.emf.codegen.ecore.genmodel.*
>>> org.eclipse.emf.ecore.*" class="Class" version="$Id: index.html,v
>>> 1.1 2007/02/21 20:19:09 wbeaton Exp $" %>
>>> <% final String oclNsURI =
>>> "http://www.eclipse.org/ocl/examples/OCL"; %>
>>> *<%boolean once = false;%>*
>>> <%@ include file="Class.javajet"%>
>>
>>> You could then change Class/declaredFieldGenFeature.insert.javajetinc
>>> to add a guard such that the body of what it generates is only done
>>> once. I.e., if (!once) { once = true; <whatever was there before> }.
>>
>> I also did this and had the error:
>>
>> Description: Duplicate local variable genFeature
>> On element: Class.java
>> In folder:
>> JETEmitters/src/org/eclipse/ocl/examples/codegen/templates/m odel
> You're sure there aren't changes you didn't tell me about. (For example,
> leaving the results of the previous changes in place so you have both a
> Class/declaredFieldGenFeature.insert.javajetinc and a
> Class/insert.javajetinc?) After all, how does adding the guard
> introduce duplicates? Clearly there's something additional you've done
> other than declare guard variable and use guard variable...
>>
>> Is there a less painful way to get EMF Validation, just like GMF
>> Validation?
>>
>> Thanks,
>> Alessander
>>
>>>> I think it's not that simple, but I don't know what to do...
>>>>
>>>> Thanks for your help!
>>>> Alessander Botti Benevides
>>>>
>>>> Ed Merks wrote:
>>>>
>>>>> Alessander,
>>>>
>>>>> This insertion happens only once, instead of once per
>>>>> feature/operation like all the other includes
>>>>
>>>>> <%@ include file="Class/insert.javajetinc" fail="silent" %>
>>>>
>>>>> Unfortunately it's at the end, which is okay, but not as nice.
>>>>
>>>>> I suppose a more hacky fix is to include a guard variable
>>>>
>>>>> <%@ jet
>>>>> package="org.eclipse.ocl.examples.codegen.templates.model"
>>>>> imports="java.util.* org.eclipse.emf.codegen.ecore.genmodel.*
>>>>> org.eclipse.emf.ecore.*" class="Class" version="$Id: index.html,v
>>>>> 1.1 2007/02/21 20:19:09 wbeaton Exp $" %>
>>>>> <% final String oclNsURI =
>>>>> "http://www.eclipse.org/ocl/examples/OCL"; %>
>>>>> <%boolean once = false;%>
>>>>> <%@ include file="Class.javajet"%>
>>>>
>>>>> and guard the part that's repeating.
>>>>
>>>>> We could add a proper "include-once insert in 2.5.
>>>>
>>>>
>>>>> Alessander Botti Benevides wrote:
>>>>>> Hi people,
>>>>>>
>>>>>> I also use the EMF OCL integration explained in
>>>>>>
>>>>
>>
http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html.
>>
>>>>
>>>>>>
>>>>>> For years, I used the templates exactly as they were in the
>>>>>> example file of this tutorial (ocl-codegen.zip). But it stop
>>>>>> working when I upgraded to EMF 2.4.x :(
>>>>>> I have no idea of how to fix this templates for the new behavior
>>>>>> of the Class.javajet file that you're talking about, and I really
>>>>>> need to use EMF Validation With OCL. Please, can you help me?
>>>>>>
>>>>>> Any help will be great,
>>>>>> Alessander Botti Benevides
>>>>>>
>>>>>> Marc Moser wrote:
>>>>>>
>>>>>>> Hi Ed,
>>>>>>
>>>>>>> Comments below.
>>>>>>
>>>>>>>> Marc,
>>>>>>>>
>>>>>>>> Comments beow.
>>>>>>>>
>>>>>>>> Marc Moser wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> We use an EMF OCL integration as explained in
>>>>>>>>>
>>>>>>
>>>>
>>
http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
>>
>>>>
>>>>>>
>>>>>>>>> Unfortunately, code generation based on our adapted templates
>>>>>>>>> stopped
>>>>>>>>> working with build M7 and newer (we are using RC4 right now).
>>>>>>>>> But it
>>>>>>>>> worked fine up to and including build M6.
>>>>>>>>>
>>>>>>>>> I could identify the "root of this problem" in the EMF template
>>>>>>>>> Class.javajet. Prior to M7, lines 277-285 looked as follows:
>>>>>>>>>
>>>>>>>>> protected boolean <%=genFeature.getUncapName()%>ESet;
>>>>>>>>>
>>>>>>>>> <%}%>
>>>>>>>>> <%}%>
>>>>>>>>> <%}%>
>>>>>>>>> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
>>>>>>>>> fail="silent" %>
>>>>>>>>> <%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
>>>>>>>>> <%}%>
>>>>>>>>> <%if (isImplementation && genClass.hasOffsetCorrection() &&
>>>>>>>>> !genClass.getImplementedGenFeatures().isEmpty()) {%>
>>>>>>>>>
>>>>>>>>> Now in RC4, the corresponding lines 306-314 look as follows:
>>>>>>>>>
>>>>>>>>> protected boolean <%=genFeature.getUncapName()%>ESet;
>>>>>>>>>
>>>>>>>>> <%}%>
>>>>>>>>> <%}%>
>>>>>>>>> <%@ include file="Class/declaredFieldGenFeature.insert.javajetinc"
>>>>>>>>> fail="silent" %>
>>>>>>>>> <%@ end %><%//Class/declaredFieldGenFeature.override.javajetinc%>
>>>>>>>>> <%}%>
>>>>>>>>> <%}%>
>>>>>>>>> <%if (isImplementation && genClass.hasOffsetCorrection() &&
>>>>>>>>> !genClass.getImplementedGenFeatures().isEmpty()) {%>
>>>>>>>>>
>>>>>>>>> As you can see, one of the closing curly brace <%}%> was moved
>>>>>>>>> from
>>>>>>>>> before including declaredFieldGenFeature.insert.javajetinc to
>>>>>>>>> after
>>>>>>>>> including it.
>>>>>>>>>
>>>>>>>>> Is there a reason for this new behavior, or was this
>>>>>>>>> accidentally (ok,
>>>>>>>>> I am pretty sure there is a reason :-)?
>>>>>>>>
>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=230410
>>>>>>>>
>>>>>>>>> Also note that this closing
>>>>>>>>> brace actually closes a for-loop, so while before the insert
>>>>>>>>> template
>>>>>>>>> was inserted after the for loop, it is now inside the iteration
>>>>>>>>> of the
>>>>>>>>> foor loop.
>>>>>>>>>
>>>>>>>> Maybe I screwed it up...
>>>>>>>>> In our case this leads to several problems. We added e.g. a
>>>>>>>>> field to
>>>>>>>>> each class by simply declaring it in
>>>>>>>>> Class/declaredFieldGenFeature.insert.javajetinc Now, this
>>>>>>>>> doesn't work
>>>>>>>>> anymore because the field will be generated several times because
>>>>>>>>> Class/declaredFieldGenFeature.insert.javajetinc is called inside a
>>>>>>>>> loop. There are also naming clashes now, and other problems.
>>>>>>>>>
>>>>>>>> Hmmm. I'm not sure I did screw up though. I think this
>>>>>>>> template should be invoked once per feature so you'd better be
>>>>>>>> sure the code generated is different for each feature...
>>>>>>
>>>>>>> So far, the insert-template was called only once and the override
>>>>>>> template did not work. Now with the bug fix, the override template
>>>>>>> works, but the fix also changes the way the insert-tamplate is
>>>>>>> called,
>>>>>>> because now it is called once per feature. But I agree with you that
>>>>>>> this is probably how it should have been from the beginning.
>>>>>>> Thus, if
>>>>>>> you tell me it will stay the way it is now, I'm happy with it and
>>>>>>> I'll
>>>>>>> adapt my templates accordingly.
>>>>>>
>>>>>>>>> Thanks for your help!
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>> Marc
>>>>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Previous Topic:Implement comparable in Rose model
Next Topic:Deleting objects with non containment references
Goto Forum:
  


Current Time: Thu Apr 25 06:13:22 GMT 2024

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

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

Back to the top