Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Extending/overriding the generated EMF model
Extending/overriding the generated EMF model [message #423218] Thu, 25 September 2008 03:36 Go to next message
Bob is currently offline BobFriend
Messages: 44
Registered: July 2009
Member
Hi all,

We all know the obvious (documented) way to extend/override a model is to
add your own methods in the implementation class and if applicable remove
the @generated tag and all will be well.

However, there are some valid claims (valid in my opinion) that user code
should not be mixed in with generated code. One suggestion is to extend the
implementation class, but then one must be careful to make sure that the
factory creates the correct implementation class, that is, the extended
version. So the factory has to be updated, but maintaining that we don't
modify generated code we extend the factory implementation, but that would
break the factory interface attribute eInstance as it calls the static
"init" method in the generated implementation, so in the end there is no
choice but to either update the eInstance attribute to call an "init" method
in the extended factory, or to create an instance of the extended factory
manually.

What are the thoughts on this issue? Should methods be overridden and
classes extended in the generated implementations? Or is there some sensible
way to separate manually written code which gives advantages when testing
code coverage on non-generated code?

Thanks

Bob
Re: Extending/overriding the generated EMF model [message #423234 is a reply to message #423218] Thu, 25 September 2008 10:46 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31486
Registered: July 2009
Senior Member
Bob,

Comments below.

Bob wrote:
> Hi all,
>
> We all know the obvious (documented) way to extend/override a model is to
> add your own methods in the implementation class and if applicable remove
> the @generated tag and all will be well.
>
> However, there are some valid claims (valid in my opinion) that user code
> should not be mixed in with generated code.
Darned, another purist shows up! Personally I think the claims are
largely driven by the thinnest of reasons and ignore the costs and
complexity that being pure introduces.
> One suggestion is to extend the
> implementation class, but then one must be careful to make sure that the
> factory creates the correct implementation class, that is, the extended
> version.
And what about if you need to add methods to the interface not just
implementations to the class? If adding EOperations is sufficient, they
how about defining operations with body annotations an not modifying the
generated code at all?
> So the factory has to be updated,
Also derived classes have to use the right base class.
> but maintaining that we don't
> modify generated code we extend the factory implementation, but that would
> break the factory interface attribute eInstance as it calls the static
> "init" method in the generated implementation, so in the end there is no
> choice but to either update the eInstance attribute to call an "init" method
> in the extended factory, or to create an instance of the extended factory
> manually.
>
You'll need to modify a bunch of things, including base classes if you
have a hierarchy of classes. And of course downstream models that
extend your model would have to be aware of this as well.
> What are the thoughts on this issue?
Snap out of it! :-P Use Mint to highlight your @generated methods so
you can pretend you're looking at a separate file that has just your
changes.
> Should methods be overridden and
> classes extended in the generated implementations?
No.
> Or is there some sensible
> way to separate manually written code which gives advantages when testing
> code coverage on non-generated code?
>
Are the clients who use your code going to care that you've separated
things and tested them separately? I think all they'll care about is
that your code works. And they'll prefer it to be as simple as possible
with as little byte code as necessary.
> Thanks
>
> Bob
>
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Extending/overriding the generated EMF model [message #423333 is a reply to message #423234] Mon, 29 September 2008 01:17 Go to previous messageGo to next message
Bob is currently offline BobFriend
Messages: 44
Registered: July 2009
Member
"Ed Merks" <Ed.Merks@gmail.com> wrote in message
news:gbfq61$376$1@build.eclipse.org...
> Bob,
>
> Comments below.
>
> Bob wrote:
>> Hi all,
>>
>> We all know the obvious (documented) way to extend/override a model is to
>> add your own methods in the implementation class and if applicable remove
>> the @generated tag and all will be well.
>>
>> However, there are some valid claims (valid in my opinion) that user code
>> should not be mixed in with generated code.
> Darned, another purist shows up! Personally I think the claims are
> largely driven by the thinnest of reasons and ignore the costs and
> complexity that being pure introduces.


Guess what, I'm not the purist :), I prefer to do it the way all EMF
documentation suggests, because of the complexity that could be introduced
from the proposed solution, and anything I haven't thought of yet. But I
deliberately wrote the post as best I could to take the purist argument so I
could gather all the pros and cons possible. It worked :), but I have more
questions so that I can present the best argument on my side (or prove
myself wrong, I came here looking to do one of the two).


>> One suggestion is to extend the implementation class, but then one must
>> be careful to make sure that the factory creates the correct
>> implementation class, that is, the extended version.
> And what about if you need to add methods to the interface not just
> implementations to the class?

I'm not sure I understand, but wouldn't this still be possible just
providing the implementation in the extended implementation class and
leaving the generated implementation that throws an unsupported exception
(or whatever the default is?).


> If adding EOperations is sufficient, they how about defining operations
> with body annotations an not modifying the generated code at all?


I don't understand again about the annotations, is there some documenation I
can read on this area?


>> So the factory has to be updated,
> Also derived classes have to use the right base class.
>> but maintaining that we don't modify generated code we extend the
>> factory implementation, but that would break the factory interface
>> attribute eInstance as it calls the static "init" method in the generated
>> implementation, so in the end there is no choice but to either update the
>> eInstance attribute to call an "init" method in the extended factory, or
>> to create an instance of the extended factory manually.
>>
> You'll need to modify a bunch of things, including base classes if you
> have a hierarchy of classes. And of course downstream models that extend
> your model would have to be aware of this as well.


Care to make a list for me? :). Personally I think it is super-ugly
modifying that eInstance attribute.

However, on the purist argument, which I must admit has some merit,
separation could be good, wouldn't a purist claim that EMF is not designed
well to allow separation of custom code and generated? I mean, trusting a
generated model and having completely separate custom code would allow focus
on testing the custom code and code coverage tools to be configured to only
report on the custom code.

>> What are the thoughts on this issue?
> Snap out of it! :-P Use Mint to highlight your @generated methods so you
> can pretend you're looking at a separate file that has just your changes.

I'll take a look at Mint.


> Are the clients who use your code going to care that you've separated
> things and tested them separately? I think all they'll care about is that
> your code works. And they'll prefer it to be as simple as possible with
> as little byte code as necessary.

We are the clients, but none-the-less, the clients shouldn't have any idea
about any of the implementation, in fact in most cases I would expect that
the client doesn't need to know that it is even an EMF model, UNLESS, they
specifically want to use EMF technology - perhaps that is another argument,
probably to exploit the best features the client would want to know that it
is EMF?

Cheers

Bob.
Re: Extending/overriding the generated EMF model [message #423346 is a reply to message #423333] Mon, 29 September 2008 11:27 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31486
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------010609010401040704080002
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Bob,

Comments below.

Bob wrote:
> "Ed Merks" <Ed.Merks@gmail.com> wrote in message
> news:gbfq61$376$1@build.eclipse.org...
>
>> Bob,
>>
>> Comments below.
>>
>> Bob wrote:
>>
>>> Hi all,
>>>
>>> We all know the obvious (documented) way to extend/override a model is to
>>> add your own methods in the implementation class and if applicable remove
>>> the @generated tag and all will be well.
>>>
>>> However, there are some valid claims (valid in my opinion) that user code
>>> should not be mixed in with generated code.
>>>
>> Darned, another purist shows up! Personally I think the claims are
>> largely driven by the thinnest of reasons and ignore the costs and
>> complexity that being pure introduces.
>>
>
>
> Guess what, I'm not the purist :), I prefer to do it the way all EMF
> documentation suggests, because of the complexity that could be introduced
> from the proposed solution, and anything I haven't thought of yet. But I
> deliberately wrote the post as best I could to take the purist argument so I
> could gather all the pros and cons possible. It worked :), but I have more
> questions so that I can present the best argument on my side (or prove
> myself wrong, I came here looking to do one of the two).
>
Aren't you sneaky. :-P
>
>
>>> One suggestion is to extend the implementation class, but then one must
>>> be careful to make sure that the factory creates the correct
>>> implementation class, that is, the extended version.
>>>
>> And what about if you need to add methods to the interface not just
>> implementations to the class?
>>
>
> I'm not sure I understand, but wouldn't this still be possible just
> providing the implementation in the extended implementation class and
> leaving the generated implementation that throws an unsupported exception
> (or whatever the default is?).
>
The point is that EMF generates an interface and an implementation
class. The "separate hand written code" solution has only addressed the
second half of this. For the sake of argument, suppose you needed (more
like wanted I suppose) to add a static final constant to the
interface. If I remember the pattern correctly, it was something like
this. FooGen has all the generated interface. Foo extends FooGen and
you add your hand written stuff there. FooGenImpl is the generated
implementation class and implements Foo. Finally FooImpl extends
FooGenImpl and implements Foo. Or something like that. To me it was
always so horrible (and was made worse by the fact that we had a MetaFoo
that extended EClass and a MetaFooImpl that extended EClassImpl. as
well,or whatever the heck is was called). Reducing 6 artifacts down to
2 resulted in a significant footprint reduction.
>
>
>> If adding EOperations is sufficient, they how about defining operations
>> with body annotations an not modifying the generated code at all?
>>
>
>
> I don't understand again about the annotations, is there some documenation I
> can read on this area?
>
Here's an example from SDO.ecore

<eClassifiers xsi:type="ecore:EClass" name="EDataObject"
eSuperTypes="../../org.eclipse.emf.ecore/model/Ecore.ecore#//EObject
#//DataObject">
<eOperations name="getInstanceProperties">
<eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
<details key="body" value="return
&lt;%org.eclipse.emf.ecore.sdo.util.SDOUtil%>.getInstanceProperties(this); "/>
</eAnnotations>
<eGenericType eClassifier="#//EJavaList">
<eTypeArguments eClassifier="#//Property"/>
</eGenericType>
</eOperations>
</eClassifiers>

Any operation can have a body annotation, which is the Java code that
will be stuffed into the generated Impl class's method. You can
surround fully qualified class names with <%a.b.C%> so that they will be
imported (if possible).
>
>
>>> So the factory has to be updated,
>>>
>> Also derived classes have to use the right base class.
>>
>>> but maintaining that we don't modify generated code we extend the
>>> factory implementation, but that would break the factory interface
>>> attribute eInstance as it calls the static "init" method in the generated
>>> implementation, so in the end there is no choice but to either update the
>>> eInstance attribute to call an "init" method in the extended factory, or
>>> to create an instance of the extended factory manually.
>>>
>>>
>> You'll need to modify a bunch of things, including base classes if you
>> have a hierarchy of classes. And of course downstream models that extend
>> your model would have to be aware of this as well.
>>
>
>
> Care to make a list for me? :). Personally I think it is super-ugly
> modifying that eInstance attribute.
>
And that's only the start! :-P
> However, on the purist argument, which I must admit has some merit,
> separation could be good, wouldn't a purist claim that EMF is not designed
> well to allow separation of custom code and generated?
I'd suggest, tongue in cheek, that they go find a well-designed
alternative and use that instead of bothering me. :-P

> I mean, trusting a
> generated model and having completely separate custom code would allow focus
> on testing the custom code and code coverage tools to be configured to only
> report on the custom code.
>
No, I don't buy that argument at all. Even when you have generated
code, you need to take responsibility for the functioning of the system
as a whole. And even if this were a strong argument, it still comes
down to a tools issue. Coverage of @generated methods isn't important
so filter them please...
>
>>> What are the thoughts on this issue?
>>>
>> Snap out of it! :-P Use Mint to highlight your @generated methods so you
>> can pretend you're looking at a separate file that has just your changes.
>>
>
> I'll take a look at Mint.
>
>
>
>> Are the clients who use your code going to care that you've separated
>> things and tested them separately? I think all they'll care about is that
>> your code works. And they'll prefer it to be as simple as possible with
>> as little byte code as necessary.
>>
>
> We are the clients, but none-the-less, the clients shouldn't have any idea
> about any of the implementation, in fact in most cases I would expect that
> the client doesn't need to know that it is even an EMF model, UNLESS, they
> specifically want to use EMF technology - perhaps that is another argument,
> probably to exploit the best features the client would want to know that it
> is EMF?
>
We do have options to suppress EMF metadata, suppress @model
annotations, suppress EMF types (EList -> List, EMap -> Map) so yes,
it's possible to create a "pure" API that has no evidence of EMF. This
makes some of our clients really happy. Similarly the SDO facade to
hide EMF made some clients really happy too (actually I assume that it
does because I've not seen significant evidence of that). In any case,
soon enough either the client directly, or their clients in turn
indirectly, want XML serialization, notification, copy, change recording
and all the other handy dandy things EMF provides. Casting solves such
problems nicely, but begs the question of what the purity really bought
given that casting is shockingly expensive and simply makes explicit
assumptions implicit instead...
> Cheers
>
> Bob.
>
>
>

--------------010609010401040704080002
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">
Bob,<br>
<br>
Comments below.<br>
<br>
Bob wrote:
<blockquote cite="mid:gbpaad$p7u$1@build.eclipse.org" type="cite">
<pre wrap="">"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com">&lt;Ed.Merks@gmail.com&gt;</a> wrote in message
<a class="moz-txt-link-freetext" href="news:gbfq61$376$1@build.eclipse.org">news:gbfq61$376$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Bob,

Comments below.

Bob wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi all,

We all know the obvious (documented) way to extend/override a model is to
add your own methods in the implementation class and if applicable remove
the @generated tag and all will be well.

However, there are some valid claims (valid in my opinion) that user code
should not be mixed in with generated code.
</pre>
</blockquote>
<pre wrap="">Darned, another purist shows up! Personally I think the claims are
largely driven by the thinnest of reasons and ignore the costs and
complexity that being pure introduces.
</pre>
</blockquote>
<pre wrap=""><!---->

Guess what, I'm not the purist :), I prefer to do it the way all EMF
documentation suggests, because of the complexity that could be introduced
from the proposed solution, and anything I haven't thought of yet. But I
deliberately wrote the post as best I could to take the purist argument so I
could gather all the pros and cons possible. It worked :), but I have more
questions so that I can present the best argument on my side (or prove
myself wrong, I came here looking to do one of the two).
</pre>
</blockquote>
Aren't you sneaky. :-P<br>
<blockquote cite="mid:gbpaad$p7u$1@build.eclipse.org" type="cite">
<pre wrap="">

</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> One suggestion is to extend the implementation class, but then one must
be careful to make sure that the factory creates the correct
implementation class, that is, the extended version.
</pre>
</blockquote>
<pre wrap="">And what about if you need to add methods to the interface not just
implementations to the class?
</pre>
</blockquote>
<pre wrap=""><!---->
I'm not sure I understand, but wouldn't this still be possible just
providing the implementation in the extended implementation class and
leaving the generated implementation that throws an unsupported exception
(or whatever the default is?).
</pre>
</blockquote>
The point is that EMF generates an interface and an implementation
class. The "separate hand written code" solution has only addressed the
second half of this.&nbsp; For the sake of argument, suppose you needed
(more like wanted I suppose) to add a static final constant to the
interface.&nbsp;&nbsp; If I remember the pattern correctly, it was something like
this.&nbsp; FooGen has all the generated interface.&nbsp; Foo extends FooGen and
you add your hand written stuff there.&nbsp; FooGenImpl is the generated
implementation class and implements Foo.&nbsp; Finally FooImpl extends
FooGenImpl and implements Foo.&nbsp;&nbsp; Or something like that.&nbsp; To me it was
always so horrible (and was made worse by the fact that we had a
MetaFoo that extended EClass and a MetaFooImpl that extended
EClassImpl. as well,or whatever the heck is was called).&nbsp; Reducing 6
artifacts down to 2 resulted in a significant footprint reduction.<br>
<blockquote cite="mid:gbpaad$p7u$1@build.eclipse.org" type="cite">
<pre wrap="">

</pre>
<blockquote type="cite">
<pre wrap=""> If adding EOperations is sufficient, they how about defining operations
with body annotations an not modifying the generated code at all?
</pre>
</blockquote>
<pre wrap=""><!---->

I don't understand again about the annotations, is there some documenation I
can read on this area?
</pre>
</blockquote>
Here's an example from SDO.ecore<br>
<br>
&nbsp; &lt;eClassifiers xsi:type="ecore:EClass" name="EDataObject"
eSuperTypes="../../org.eclipse.emf.ecore/model/Ecore.ecore#//EObject
#//DataObject"&gt;<br>
&nbsp;&nbsp;&nbsp; &lt;eOperations name="getInstanceProperties"&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;eAnnotations
source=<a class="moz-txt-link-rfc2396E" href="http://www.eclipse.org/emf/2002/GenModel">"http://www.eclipse.org/emf/2002/GenModel"</a>&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;details key="body" value="return
&amp;lt;%org.eclipse.emf.ecore.sdo.util.SDOUtil%&gt; .getInstanceProperties(this); "/&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/eAnnotations&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;eGenericType eClassifier="#//EJavaList"&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &lt;eTypeArguments eClassifier="#//Property"/&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/eGenericType&gt;<br>
&nbsp;&nbsp;&nbsp; &lt;/eOperations&gt;<br>
&nbsp; &lt;/eClassifiers&gt;<br>
<br>
Any operation can have a body annotation, which is the Java code that
will be stuffed into the generated Impl class's method.&nbsp; You can
surround fully qualified class names with &lt;%a.b.C%&gt; so that they
will be imported (if possible).<br>
<blockquote cite="mid:gbpaad$p7u$1@build.eclipse.org" type="cite">
<pre wrap="">

</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">So the factory has to be updated,
</pre>
</blockquote>
<pre wrap="">Also derived classes have to use the right base class.
</pre>
<blockquote type="cite">
<pre wrap=""> but maintaining that we don't modify generated code we extend the
factory implementation, but that would break the factory interface
attribute eInstance as it calls the static "init" method in the generated
implementation, so in the end there is no choice but to either update the
eInstance attribute to call an "init" method in the extended factory, or
to create an instance of the extended factory manually.

</pre>
</blockquote>
<pre wrap="">You'll need to modify a bunch of things, including base classes if you
have a hierarchy of classes. And of course downstream models that extend
your model would have to be aware of this as well.
</pre>
</blockquote>
<pre wrap=""><!---->

Care to make a list for me? :). Personally I think it is super-ugly
modifying that eInstance attribute.
</pre>
</blockquote>
And that's only the start! :-P<br>
<blockquote cite="mid:gbpaad$p7u$1@build.eclipse.org" type="cite">
<pre wrap="">
However, on the purist argument, which I must admit has some merit,
separation could be good, wouldn't a purist claim that EMF is not designed
well to allow separation of custom code and generated?</pre>
</blockquote>
I'd suggest, tongue in cheek, that they go find a well-designed
alternative and use that instead of bothering me. :-P<br>
<br>
<blockquote cite="mid:gbpaad$p7u$1@build.eclipse.org" type="cite">
<pre wrap=""> I mean, trusting a
generated model and having completely separate custom code would allow focus
on testing the custom code and code coverage tools to be configured to only
report on the custom code.
</pre>
</blockquote>
No, I don't buy that argument at all.&nbsp;&nbsp; Even when you have generated
code, you need to take responsibility for the functioning of the system
as a whole.&nbsp; And even if this were a strong argument, it still comes
down to a tools issue.&nbsp; Coverage of @generated methods isn't important
so filter them please...<br>
<blockquote cite="mid:gbpaad$p7u$1@build.eclipse.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">What are the thoughts on this issue?
</pre>
</blockquote>
<pre wrap="">Snap out of it! :-P Use Mint to highlight your @generated methods so you
can pretend you're looking at a separate file that has just your changes.
</pre>
</blockquote>
<pre wrap=""><!---->
I'll take a look at Mint.


</pre>
<blockquote type="cite">
<pre wrap="">Are the clients who use your code going to care that you've separated
things and tested them separately? I think all they'll care about is that
your code works. And they'll prefer it to be as simple as possible with
as little byte code as necessary.
</pre>
</blockquote>
<pre wrap=""><!---->
We are the clients, but none-the-less, the clients shouldn't have any idea
about any of the implementation, in fact in most cases I would expect that
the client doesn't need to know that it is even an EMF model, UNLESS, they
specifically want to use EMF technology - perhaps that is another argument,
probably to exploit the best features the client would want to know that it
is EMF?
</pre>
</blockquote>
We do have options to suppress EMF metadata, suppress @model
annotations, suppress EMF types (EList -&gt; List, EMap -&gt; Map) so
yes, it's possible to create a "pure" API that has no evidence of
EMF.&nbsp;&nbsp; This makes some of our clients really happy.&nbsp;&nbsp; Similarly the SDO
facade to hide EMF made some clients really happy too (actually I
assume that it does because I've not seen significant evidence of
that).&nbsp; In any case, soon enough either the client directly, or their
clients in turn indirectly, want XML serialization, notification, copy,
change recording and all the other handy dandy things EMF provides.&nbsp;&nbsp;
Casting solves such problems nicely, but begs the question of what the
purity really bought given that casting is shockingly expensive and
simply makes explicit assumptions implicit instead...<br>
<blockquote cite="mid:gbpaad$p7u$1@build.eclipse.org" type="cite">
<pre wrap="">
Cheers

Bob.


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

--------------010609010401040704080002--


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Extending/overriding the generated EMF model [message #423405 is a reply to message #423346] Mon, 29 September 2008 23:48 Go to previous messageGo to next message
Bob is currently offline BobFriend
Messages: 44
Registered: July 2009
Member
This is a multi-part message in MIME format.

------=_NextPart_000_0009_01C922E1.BADEA830
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks for your help, I've got plenty to work on. :)


I'm thinking that in most cases we can probably provided a wrapper or =
utility class that adds the additional functionality. From experience in =
our models this will be a good solution that will make all happy. Of =
course there are still some issues, like implementing comparable, adding =
a sub-class just to do that is crazyness :), of course a comparator can =
be written separately and used where necessary.

On the code coverage issue, we do want to ignore coverage on generated =
methods, we use Cobertura and unfortunately there is no way to have the =
tool just ignore a particular method, so that does pose a problem.

Anyway, we will work on a solution that hopefully does not involve =
extending impl classes :).

Thanks

Bob.

"Ed Merks" <Ed.Merks@gmail.com> wrote in message =
news:gbqe2g$sf2$1@build.eclipse.org...

------=_NextPart_000_0009_01C922E1.BADEA830
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.6000.16705" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Thanks for your help, I've got plenty =
to work on.=20
:)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I'm thinking that in most cases we can =
probably=20
provided a wrapper or utility class that adds the additional =
functionality. From=20
experience in our models this will be a good solution that will make all =
happy.=20
Of course there are still some issues, like implementing comparable, =
adding a=20
sub-class just to do that is crazyness :), of course a comparator can be =
written=20
separately and used where necessary.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>On the code coverage issue, we do want =
to ignore=20
coverage on generated methods, we use Cobertura and unfortunately there =
is no=20
way to have the tool just ignore a particular method, so that does pose =
a=20
problem.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Anyway, we will work on a solution that =
hopefully=20
does not involve extending impl classes :).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Bob.</FONT></DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" &lt;<A=20
href=3D"mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>&gt; wrote in =
message=20
<A=20
=
href=3D"news:gbqe2g$sf2$1@build.eclipse.org">news:gbqe2g$sf2$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial =
size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML >

------=_NextPart_000_0009_01C922E1.BADEA830--
Re: Extending/overriding the generated EMF model [message #423551 is a reply to message #423405] Thu, 02 October 2008 07:36 Go to previous message
Knut Wannheden is currently offline Knut WannhedenFriend
Messages: 298
Registered: July 2009
Senior Member
Hi Bob

In case you haven't already read it I thought you might be interested in
this article:
http://apps.itemis.de/roller/itemislabkiel/entry/eclipse_mod eling_framework_emf_adding.

Regards

--knut

Bob wrote:
> Thanks for your help, I've got plenty to work on. :)
>
>
> I'm thinking that in most cases we can probably provided a wrapper or
> utility class that adds the additional functionality. From experience in
> our models this will be a good solution that will make all happy. Of
> course there are still some issues, like implementing comparable, adding
> a sub-class just to do that is crazyness :), of course a comparator can
> be written separately and used where necessary.
>
> On the code coverage issue, we do want to ignore coverage on generated
> methods, we use Cobertura and unfortunately there is no way to have the
> tool just ignore a particular method, so that does pose a problem.
>
> Anyway, we will work on a solution that hopefully does not involve
> extending impl classes :).
>
> Thanks
>
> Bob.
>
>
> "Ed Merks" <Ed.Merks@gmail.com <mailto:Ed.Merks@gmail.com>> wrote in
> message news:gbqe2g$sf2$1@build.eclipse.org...
>
Previous Topic:Validation of model on doSave()
Next Topic:[CDO] Does CDO not support FeatureMaps?
Goto Forum:
  


Current Time: Mon Sep 28 23:07:19 GMT 2020

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

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

Back to the top