Home » Modeling » EMF » declared vs implemented in jet
|
| Re: declared vs implemented in jet [message #419003 is a reply to message #419002] |
Wed, 07 May 2008 20:19   |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------040905010701060509020300
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Gary,
If you look in the Class.javajet, which is the template used to generate
interfaces, impls, or the combination of the two if interfaces are
suppressed, you'll see this
<%for (GenOperation genOperation : (isImplementation ?
genClass.getImplementedGenOperations() :
genClass.getDeclaredGenOperations())) {%>
So when generating the implementation, i.e., the actual Java class,
these are the operations that need to be implemented, but while
generating an interface, the declared operations must appear. How are
they different you might ask? That's a very good question! When a
class C has as super types both A and B, CImpl will extend AImpl and
while the interface for C only needs to declare the operations
introduced by C, CImpl will need to implement B's operations as well as
the ones introduced by C.
gary thompson wrote:
> Dear All
>
> just a quick question what is the difference between a declared and an
> implemented feature? eg genClass.getImplementedGenOperations() vs
> genClass.getDeclaredGenOperations()
>
> regards
> gary
>
--------------040905010701060509020300
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">
Gary,<br>
<br>
If you look in the Class.javajet, which is the template used to
generate interfaces, impls, or the combination of the two if interfaces
are suppressed, you'll see this<br>
<blockquote><small><%for (GenOperation genOperation :
(isImplementation ? genClass.getImplementedGenOperations() :
genClass.getDeclaredGenOperations())) {%></small><br>
</blockquote>
So when generating the implementation, i.e., the actual Java class,
these are the operations that need to be implemented, but while
generating an interface, the declared operations must appear.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: declared vs implemented in jet [message #419015 is a reply to message #419003] |
Wed, 07 May 2008 22:11 |
gary s thompson
Messages: 92
Registered: July 2009 |
Member |
|
|
Ed Merks wrote:
> Gary,
> If you look in the Class.javajet, which is the template used to generate
> interfaces, impls, or the combination of the two if interfaces are
> suppressed, you'll see this
> <%for (GenOperation genOperation : (isImplementation ?
> genClass.getImplementedGenOperations() :
> genClass.getDeclaredGenOperations())) {%>
Dear Ed
yep thats what I was looking at and what elicited the question... So heres
the back story
> So when generating the implementation, i.e., the actual Java class,
> these are the operations that need to be implemented, but while
> generating an interface, the declared operations must appear. How are
> they different you might ask? That's a very good question! When a
> class C has as super types both A and B, CImpl will extend AImpl and
> while the interface for C only needs to declare the operations
> introduced by C, CImpl will need to implement B's operations as well as
> the ones introduced by C.
Now that sort of fits to what I expected, but I wasn't sure... so that
really helps ;-)
but one good question deserves another (well the new question may not be
good)
I have two classes A and B. B inherits from A and A is abstract (the class
is abstract but I couldn't find a way to make abstract methods) and my
ecore defines opA on both A and B. However, I only get opA in A not B
(note also that I am currently suppressing interfaces in my genmodel). Now
if I look at genClass.getImplementedGenOperations() on B I don't get opA
but it is in genClass.getDeclaredGenOperations()...
regards
gary
> gary thompson wrote:
>> Dear All
>>
>> just a quick question what is the difference between a declared and an
>> implemented feature? eg genClass.getImplementedGenOperations() vs
>> genClass.getDeclaredGenOperations()
>>
>> regards
>> gary
>>
|
|
|
| Re: declared vs implemented in jet [message #419017 is a reply to message #419015] |
Wed, 07 May 2008 22:15 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Gary,
There's no support for abstract methods:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=181532 You could remove
the @generated and mark them abstract manually...
gary thompson wrote:
> Ed Merks wrote:
>
>> Gary,
>
>> If you look in the Class.javajet, which is the template used to
>> generate interfaces, impls, or the combination of the two if
>> interfaces are suppressed, you'll see this
>
>> <%for (GenOperation genOperation : (isImplementation ?
>> genClass.getImplementedGenOperations() :
>> genClass.getDeclaredGenOperations())) {%>
>
> Dear Ed
>
> yep thats what I was looking at and what elicited the question... So
> heres the back story
>
>> So when generating the implementation, i.e., the actual Java class,
>> these are the operations that need to be implemented, but while
>> generating an interface, the declared operations must appear. How
>> are they different you might ask? That's a very good question! When
>> a class C has as super types both A and B, CImpl will extend AImpl
>> and while the interface for C only needs to declare the operations
>> introduced by C, CImpl will need to implement B's operations as well
>> as the ones introduced by C.
>
> Now that sort of fits to what I expected, but I wasn't sure... so that
> really helps ;-)
>
> but one good question deserves another (well the new question may not
> be good)
>
> I have two classes A and B. B inherits from A and A is abstract (the
> class is abstract but I couldn't find a way to make abstract methods)
> and my ecore defines opA on both A and B. However, I only get opA in A
> not B (note also that I am currently suppressing interfaces in my
> genmodel). Now if I look at genClass.getImplementedGenOperations() on
> B I don't get opA but it is in genClass.getDeclaredGenOperations()...
>
> regards
> gary
>
>
>
>> gary thompson wrote:
>>> Dear All
>>>
>>> just a quick question what is the difference between a declared and
>>> an implemented feature? eg genClass.getImplementedGenOperations() vs
>>> genClass.getDeclaredGenOperations()
>>>
>>> regards
>>> gary
>>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: declared vs implemented in jet [message #419053 is a reply to message #419051] |
Fri, 09 May 2008 11:46 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Gary,
Comments below.
gary thompson wrote:
> gary thompson wrote:
>
>> Ed Merks wrote:
>
>>> Gary,
>
>>> There's no support for abstract methods:
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=181532 You could
>>> remove the @generated and mark them abstract manually...
>
>> there were too many ;-) I defined an annotation and have overridden
>> genOperation.override.javajetinc
>
>
>
> [snip]
>
> I hope it is not rude if I ask if anyone has any thoughts on the
> second conundrum here (if I am being dense about what is going on I
> apologize ;-)) I have reedited the question to hopefully make it
> clearer what my problem is.
Sorry I didn't realize part of the question wasn't answered....
>
>> I have two classes A and B. B inherits from A and A is abstract (the
>> class
> is > abstract but I couldn't find a way to make abstract methods)
> ^^^^^^^^^^^^^^^^
> and now I know that thats expected!
>
> and my ecore defines opA on both A and B. However, I only get opA in
> the generated code of A not in the generated code of B (note also that
> I am currently suppressing interfaces in my genmodel). Now if > I look
> at genClass.getImplementedGenOperations() on B I don't get opA but it
> > is in genClass.getDeclaredGenOperations() so that fits with the
> output, However, it still doesn't seem to explain why opA isn't in the
> output of genClass.getImplementedGenOperations() for class B
Because the generator is trying to be smart. Unless the operation has a
body, generating the operation in B would produce a stub that you'd have
to hand modify to do something useful. And because the A class already
contains an implementation (presumably) since the generator knows it
generated an implementation there, it figures that generating a stub
that needs to be hand changed is likely not a desirable thing. In EMF
2.4 I do recall changing this somewhat so that if the operation defined
in B has a body annotation as well, we don't want the generator to
ignore that, so it will generate a method in BImpl with that body for
that case.
>
> regards
> gary
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: declared vs implemented in jet [message #419277 is a reply to message #419053] |
Fri, 16 May 2008 07:30 |
gary s thompson
Messages: 92
Registered: July 2009 |
Member |
|
|
Ed Merks wrote:
> Gary,
> Comments below.
> gary thompson wrote:
>> gary thompson wrote:
>>
>>> Ed Merks wrote:
>>
>>>> Gary,
>>
>>>> There's no support for abstract methods:
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=181532 You could
>>>> remove the @generated and mark them abstract manually...
>>
>>> there were too many ;-) I defined an annotation and have overridden
>>> genOperation.override.javajetinc
>>
>>
>>
>> [snip]
>>
>> I hope it is not rude if I ask if anyone has any thoughts on the
>> second conundrum here (if I am being dense about what is going on I
>> apologize ;-)) I have reedited the question to hopefully make it
>> clearer what my problem is.
> Sorry I didn't realize part of the question wasn't answered....
>>
>>> I have two classes A and B. B inherits from A and A is abstract (the
>>> class
>> is > abstract but I couldn't find a way to make abstract methods)
>> ^^^^^^^^^^^^^^^^
>> and now I know that thats expected!
>>
>> and my ecore defines opA on both A and B. However, I only get opA in
>> the generated code of A not in the generated code of B (note also that
>> I am currently suppressing interfaces in my genmodel). Now if > I look
>> at genClass.getImplementedGenOperations() on B I don't get opA but it
>> > is in genClass.getDeclaredGenOperations() so that fits with the
>> output, However, it still doesn't seem to explain why opA isn't in the
>> output of genClass.getImplementedGenOperations() for class B
> Because the generator is trying to be smart. Unless the operation has a
> body, generating the operation in B would produce a stub that you'd have
> to hand modify to do something useful. And because the A class already
> contains an implementation (presumably) since the generator knows it
> generated an implementation there, it figures that generating a stub
> that needs to be hand changed is likely not a desirable thing. In EMF
> 2.4 I do recall changing this somewhat so that if the operation defined
> in B has a body annotation as well, we don't want the generator to
> ignore that, so it will generate a method in BImpl with that body for
> that case.
Hi Ed
just to let you know I installed 2.4 and added a empty body element to all
my over riding operation elements. However, the methods still get elided
at genmodel time; do I need to do more work in the empty body?
regards and many thanks
gary
|
|
|
| Re: declared vs implemented in jet [message #419284 is a reply to message #419277] |
Fri, 16 May 2008 15:07 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------060901030101090009020907
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Gary,
Will this code in GenOperationImpl return true for hasBody?
protected String getBody()
{
EOperation eOperation = getEcoreOperation();
EAnnotation eAnnotation =
eOperation.getEAnnotation(GenModelPackage.eNS_URI);
return eAnnotation == null ? null :
(String)eAnnotation.getDetails().get("body");
}
public boolean hasBody()
{
return getBody() != null;
}
public String getBody(String indentation)
{
String body = getBody();
I'm happy to look at a test case if you have one.
gary thompson wrote:
> Ed Merks wrote:
>
>> Gary,
>
>> Comments below.
>
>> gary thompson wrote:
>>> gary thompson wrote:
>>>
>>>> Ed Merks wrote:
>>>
>>>>> Gary,
>>>
>>>>> There's no support for abstract methods:
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=181532 You could
>>>>> remove the @generated and mark them abstract manually...
>>>
>>>> there were too many ;-) I defined an annotation and have overridden
>>>> genOperation.override.javajetinc
>>>
>>>
>>>
>>> [snip]
>>>
>>> I hope it is not rude if I ask if anyone has any thoughts on the
>>> second conundrum here (if I am being dense about what is going on I
>>> apologize ;-)) I have reedited the question to hopefully make it
>>> clearer what my problem is.
>> Sorry I didn't realize part of the question wasn't answered....
>>>
>>>> I have two classes A and B. B inherits from A and A is abstract
>>>> (the class
>>> is > abstract but I couldn't find a way to make abstract methods)
>>> ^^^^^^^^^^^^^^^^
>>> and now I know that thats
>>> expected!
>>>
>>> and my ecore defines opA on both A and B. However, I only get opA
>>> in the generated code of A not in the generated code of B (note also
>>> that I am currently suppressing interfaces in my genmodel). Now if >
>>> I look at genClass.getImplementedGenOperations() on B I don't get
>>> opA but it > is in genClass.getDeclaredGenOperations() so that fits
>>> with the output, However, it still doesn't seem to explain why opA
>>> isn't in the output of genClass.getImplementedGenOperations() for
>>> class B
>> Because the generator is trying to be smart. Unless the operation
>> has a body, generating the operation in B would produce a stub that
>> you'd have to hand modify to do something useful. And because the A
>> class already contains an implementation (presumably) since the
>> generator knows it generated an implementation there, it figures that
>> generating a stub that needs to be hand changed is likely not a
>> desirable thing. In EMF 2.4 I do recall changing this somewhat so
>> that if the operation defined in B has a body annotation as well, we
>> don't want the generator to ignore that, so it will generate a method
>> in BImpl with that body for that case.
>
> Hi Ed just to let you know I installed 2.4 and added a empty body
> element to all my over riding operation elements. However, the methods
> still get elided at genmodel time; do I need to do more work in the
> empty body?
>
> regards and many thanks
> gary
>
>
--------------060901030101090009020907
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">
Gary,<br>
<br>
Will this code in GenOperationImpl return true for hasBody?<br>
<blockquote><small>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: declared vs implemented in jet [message #419291 is a reply to message #419284] |
Fri, 16 May 2008 21:40 |
gary s thompson
Messages: 92
Registered: July 2009 |
Member |
|
|
Ed Merks wrote:
> Gary,
> Will this code in GenOperationImpl return true for hasBody?
> protected String getBody()
> {
> EOperation eOperation = getEcoreOperation();
> EAnnotation eAnnotation =
> eOperation.getEAnnotation(GenModelPackage.eNS_URI);
> return eAnnotation == null ? null :
> (String)eAnnotation.getDetails().get("body");
> }
> public boolean hasBody()
> {
> return getBody() != null;
> }
> public String getBody(String indentation)
> {
> String body = getBody();
> I'm happy to look at a test case if you have one.
Sorry, yes this will return hasBody == True(!) if an annotation in the
GenModelPackage.eNS_URI has a body annotation containing an empty string.
However, it turned out my problem was something else... I had something
wrong in the JET template (I think the problem I had was I created a
static initializer block and naively pasted an @generated annotation into
its comment) This was causing the generator to crash quietly (there was a
warning in the Error Log which I have appended below). Obviously this
left the output in original state after I added the empty body to the
operations in the ecore as the JMerge didn't take place... (It was quite
insidious I had to delete my bin and source directories before I got it to
go away)
So I have yet another question or two (if you or someone else doesn't mind)
1. is it possible to tag a static initializer block with an @generated
javadoc/jmerge tag?
2. can I avoid jmerge altogether and recreate all the code every time I
generate?
nb I tried to look at the m2t jet faq and got:
------------------------------------------------------------ ------------
JET FAQ How do I write custom JMerge rules?
Jump to: navigation, search
The action you have requested is limited to users in the group user.
------------------------------------------------------------ ------------
I guess I will post to the m2t group about that one ;-)
Once again thanks for all or any help in advance
gary
stack trace in error log
java.lang.reflect.InvocationTargetException
at org.eclipse.jface.operation.ModalContext.run(ModalContext.ja va:401)
at
org.eclipse.jface.dialogs.ProgressMonitorDialog.run(Progress MonitorDialog.java:507)
at
org.eclipse.emf.codegen.ecore.genmodel.presentation.GenModel ActionBarContributor$GenerateAction.run(GenModelActionBarCon tributor.java:423)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:498 )
at
org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:582)
at
org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:499)
at
org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:410)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1154)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3398)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3030)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2394)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2358)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:22 10)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:494)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:489)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:112)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:110)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:79)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:379)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 549)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
at org.eclipse.equinox.launcher.Main.main(Main.java:1212)
Caused by: java.lang.NoClassDefFoundError: JET2Template
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoade r.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
org.eclipse.emf.codegen.jet.JETEmitter$EclipseHelper$1.loadC lass(JETEmitter.java:549)
at
org.eclipse.emf.codegen.jet.JETEmitter$EclipseHelper.initial ize(JETEmitter.java:598)
at org.eclipse.emf.codegen.jet.JETEmitter.initialize(JETEmitter .java:397)
at org.eclipse.emf.codegen.jet.JETEmitter.generate(JETEmitter.j ava:459)
at
org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generateJava(AbstractGeneratorAdapter.java:968)
at
org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generatePackageClass(GenPackageGeneratorAdap ter.java:397)
at
org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generateModel(GenPackageGeneratorAdapter.jav a:215)
at
org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGene ratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218)
at
org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generate(AbstractGeneratorAdapter.java:290)
at
org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:617)
at
org.eclipse.emf.codegen.ecore.genmodel.presentation.GenModel ActionBarContributor$GenerateAction$1.execute(GenModelAction BarContributor.java:372)
at
org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(Worksp aceModifyOperation.java:104)
at org.eclipse.core.internal.resources.Workspace.run(Workspace. java:1800)
at
org.eclipse.ui.actions.WorkspaceModifyOperation.run(Workspac eModifyOperation.java:116)
at
org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:119)
eclipse.buildId=I20080502-0100
java.version=1.6.0_03
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_GB
Command-line arguments: -os linux -ws gtk -arch x86_64
all plugins including emf from the ganymede update site
> gary thompson wrote:
>> Ed Merks wrote:
>>
>>> Gary,
>>
>>> Comments below.
>>
>>> gary thompson wrote:
>>>> gary thompson wrote:
>>>>
>>>>> Ed Merks wrote:
>>>>
>>>>>> Gary,
>>>>
>>>>>> There's no support for abstract methods:
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=181532 You could
>>>>>> remove the @generated and mark them abstract manually...
>>>>
>>>>> there were too many ;-) I defined an annotation and have overridden
>>>>> genOperation.override.javajetinc
>>>>
>>>>
>>>>
>>>> [snip]
>>>>
>>>> I hope it is not rude if I ask if anyone has any thoughts on the
>>>> second conundrum here (if I am being dense about what is going on I
>>>> apologize ;-)) I have reedited the question to hopefully make it
>>>> clearer what my problem is.
>>> Sorry I didn't realize part of the question wasn't answered....
>>>>
>>>>> I have two classes A and B. B inherits from A and A is abstract
>>>>> (the class
>>>> is > abstract but I couldn't find a way to make abstract methods)
>>>> ^^^^^^^^^^^^^^^^
>>>> and now I know that thats
>>>> expected!
>>>>
>>>> and my ecore defines opA on both A and B. However, I only get opA
>>>> in the generated code of A not in the generated code of B (note also
>>>> that I am currently suppressing interfaces in my genmodel). Now if >
>>>> I look at genClass.getImplementedGenOperations() on B I don't get
>>>> opA but it > is in genClass.getDeclaredGenOperations() so that fits
>>>> with the output, However, it still doesn't seem to explain why opA
>>>> isn't in the output of genClass.getImplementedGenOperations() for
>>>> class B
>>> Because the generator is trying to be smart. Unless the operation
>>> has a body, generating the operation in B would produce a stub that
>>> you'd have to hand modify to do something useful. And because the A
>>> class already contains an implementation (presumably) since the
>>> generator knows it generated an implementation there, it figures that
>>> generating a stub that needs to be hand changed is likely not a
>>> desirable thing. In EMF 2.4 I do recall changing this somewhat so
>>> that if the operation defined in B has a body annotation as well, we
>>> don't want the generator to ignore that, so it will generate a method
>>> in BImpl with that body for that case.
>>
>> Hi Ed just to let you know I installed 2.4 and added a empty body
>> element to all my over riding operation elements. However, the methods
>> still get elided at genmodel time; do I need to do more work in the
>> empty body?
>>
>> regards and many thanks
>> gary
>>
>>
|
|
|
| Re: declared vs implemented in jet [message #419292 is a reply to message #419291] |
Fri, 16 May 2008 22:34 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Gary,
Comments below.
gary thompson wrote:
> Ed Merks wrote:
>
>> Gary,
>
>> Will this code in GenOperationImpl return true for hasBody?
>
>> protected String getBody()
>> {
>> EOperation eOperation = getEcoreOperation();
>> EAnnotation eAnnotation =
>> eOperation.getEAnnotation(GenModelPackage.eNS_URI);
>> return eAnnotation == null ? null :
>> (String)eAnnotation.getDetails().get("body");
>> }
>
>> public boolean hasBody()
>> {
>> return getBody() != null;
>> }
>
>> public String getBody(String indentation)
>> {
>> String body = getBody();
>
>> I'm happy to look at a test case if you have one.
>
> Sorry, yes this will return hasBody == True(!) if an annotation in the
> GenModelPackage.eNS_URI has a body annotation containing an empty string.
> However, it turned out my problem was something else... I had
> something wrong in the JET template (I think the problem I had was I
> created a static initializer block and naively pasted an @generated
> annotation into its comment) This was causing the generator to crash
> quietly (there was a warning in the Error Log which I have appended
> below). Obviously this left the output in original state after I added
> the empty body to the operations in the ecore as the JMerge didn't
> take place... (It was quite insidious I had to delete my bin and
> source directories before I got it to go away)
> So I have yet another question or two (if you or someone else doesn't
> mind)
>
> 1. is it possible to tag a static initializer block with an
> @generated javadoc/jmerge tag?
We've never tried to add merge support for this. The problem is of
course identifying the instance since there's no unique signature
available for doing that.
> 2. can I avoid jmerge altogether and recreate all the code every time
> I generate?
Certainly it's possible to just overwrite the result, but we don't have
build in support in our generator to do that.
> nb I tried to look at the m2t jet faq and got:
>
> ------------------------------------------------------------ ------------
> JET FAQ How do I write custom JMerge rules?
> Jump to: navigation, search
>
> The action you have requested is limited to users in the group user.
> ------------------------------------------------------------ ------------
>
> I guess I will post to the m2t group about that one ;-)
>
> Once again thanks for all or any help in advance gary
>
>
> stack trace in error log
>
> java.lang.reflect.InvocationTargetException
> at
> org.eclipse.jface.operation.ModalContext.run(ModalContext.ja va:401)
> at
> org.eclipse.jface.dialogs.ProgressMonitorDialog.run(Progress MonitorDialog.java:507)
>
> at
> org.eclipse.emf.codegen.ecore.genmodel.presentation.GenModel ActionBarContributor$GenerateAction.run(GenModelActionBarCon tributor.java:423)
>
> at org.eclipse.jface.action.Action.runWithEvent(Action.java:498 )
> at
> org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:582)
>
> at
> org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:499)
>
> at
> org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:410)
>
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :84)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1154)
> at
> org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3398)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3030)
> at
> org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2394)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2358)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:22 10)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:494)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
>
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:489)
>
> at
> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
> at
> org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:112)
>
> at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:110)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:79)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:379)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:179)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 549)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1212)
> Caused by: java.lang.NoClassDefFoundError: JET2Template
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoade r.java:124)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
> at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at
> org.eclipse.emf.codegen.jet.JETEmitter$EclipseHelper$1.loadC lass(JETEmitter.java:549)
>
> at
> org.eclipse.emf.codegen.jet.JETEmitter$EclipseHelper.initial ize(JETEmitter.java:598)
>
> at
> org.eclipse.emf.codegen.jet.JETEmitter.initialize(JETEmitter .java:397)
> at
> org.eclipse.emf.codegen.jet.JETEmitter.generate(JETEmitter.j ava:459)
> at
> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generateJava(AbstractGeneratorAdapter.java:968)
>
> at
> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generatePackageClass(GenPackageGeneratorAdap ter.java:397)
>
> at
> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generateModel(GenPackageGeneratorAdapter.jav a:215)
>
> at
> org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGene ratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218)
>
> at
> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generate(AbstractGeneratorAdapter.java:290)
>
> at
> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:617)
>
> at
> org.eclipse.emf.codegen.ecore.genmodel.presentation.GenModel ActionBarContributor$GenerateAction$1.execute(GenModelAction BarContributor.java:372)
>
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(Worksp aceModifyOperation.java:104)
>
> at
> org.eclipse.core.internal.resources.Workspace.run(Workspace. java:1800)
> at
> org.eclipse.ui.actions.WorkspaceModifyOperation.run(Workspac eModifyOperation.java:116)
>
> at
> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:119)
>
>
> eclipse.buildId=I20080502-0100
> java.version=1.6.0_03
> java.vendor=Sun Microsystems Inc.
> BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_GB
> Command-line arguments: -os linux -ws gtk -arch x86_64
> all plugins including emf from the ganymede update site
>
>
>
>> gary thompson wrote:
>>> Ed Merks wrote:
>>>
>>>> Gary,
>>>
>>>> Comments below.
>>>
>>>> gary thompson wrote:
>>>>> gary thompson wrote:
>>>>>
>>>>>> Ed Merks wrote:
>>>>>
>>>>>>> Gary,
>>>>>
>>>>>>> There's no support for abstract methods:
>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=181532 You could
>>>>>>> remove the @generated and mark them abstract manually...
>>>>>
>>>>>> there were too many ;-) I defined an annotation and have
>>>>>> overridden genOperation.override.javajetinc
>>>>>
>>>>>
>>>>>
>>>>> [snip]
>>>>>
>>>>> I hope it is not rude if I ask if anyone has any thoughts on the
>>>>> second conundrum here (if I am being dense about what is going on
>>>>> I apologize ;-)) I have reedited the question to hopefully make it
>>>>> clearer what my problem is.
>>>> Sorry I didn't realize part of the question wasn't answered....
>>>>>
>>>>>> I have two classes A and B. B inherits from A and A is abstract
>>>>>> (the class
>>>>> is > abstract but I couldn't find a way to make abstract methods)
>>>>> ^^^^^^^^^^^^^^^^
>>>>> and now I know that thats
>>>>> expected!
>>>>>
>>>>> and my ecore defines opA on both A and B. However, I only get opA
>>>>> in the generated code of A not in the generated code of B (note
>>>>> also that I am currently suppressing interfaces in my genmodel).
>>>>> Now if > I look at genClass.getImplementedGenOperations() on B I
>>>>> don't get opA but it > is in genClass.getDeclaredGenOperations()
>>>>> so that fits with the output, However, it still doesn't seem to
>>>>> explain why opA isn't in the output of
>>>>> genClass.getImplementedGenOperations() for class B
>>>> Because the generator is trying to be smart. Unless the operation
>>>> has a body, generating the operation in B would produce a stub that
>>>> you'd have to hand modify to do something useful. And because the
>>>> A class already contains an implementation (presumably) since the
>>>> generator knows it generated an implementation there, it figures
>>>> that generating a stub that needs to be hand changed is likely not
>>>> a desirable thing. In EMF 2.4 I do recall changing this somewhat
>>>> so that if the operation defined in B has a body annotation as
>>>> well, we don't want the generator to ignore that, so it will
>>>> generate a method in BImpl with that body for that case.
>>>
>>> Hi Ed just to let you know I installed 2.4 and added a empty body
>>> element to all my over riding operation elements. However, the
>>> methods still get elided at genmodel time; do I need to do more work
>>> in the empty body?
>>>
>>> regards and many thanks
>>> gary
>>>
>>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 26 13:08:45 GMT 2024
Powered by FUDForum. Page generated in 0.04682 seconds |
] 
Search
Help
Register
Login
Home
