Eclipse Community Forums: EMF » Ecore2GenModel crippling my genmodel, why?

Help

Home

Home » Modeling » EMF » Ecore2GenModel crippling my genmodel, why?

Show: Today's Messages :: Show Polls :: Message Navigator

Ecore2GenModel crippling my genmodel, why? [message #1106729]

Wed, 11 September 2013 13:19

Tom Brus

Messages: 26
Registered: February 2011

Junior Member

Hi,

I am running Ecore2GenModel -reload under jenkins as part of a tycho build under kepler.
I discovered that some genmodels loose precious information during this action.
I dug into the code and found this weird method in ModelImporterApplication:

  protected void adjustModelImporterAfterPrepare()
  {
    GenModel genModel = getModelImporter().getGenModel();
    if (genJDKLevel != null)
    {
      genModel.setComplianceLevel(genJDKLevel);
    }
    genModel.setImportOrganizing(importOrganizing);
    genModel.setOperationReflection(false);
    genModel.setRootExtendsClass("org.eclipse.emf.ecore.impl.EObjectImpl");
    // Subclasses may overwrite
  }

The OperationReflection and RootExtendsClass fields are exactly the fields that I noticed were lost in the process.

The model is first read correctly, then all the details are moved correctly to a new model and then, bang, some fields are overwritten with constant values. I am confused.

Can someone deconfuse me?

Tom Brus

P.S. as a workaround I have put some code around the Ecore2GenModel that will preserve those field.

Report message to a moderator

Re: Ecore2GenModel crippling my genmodel, why? [message #1106742 is a reply to message #1106729]

Wed, 11 September 2013 13:41

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

GenModel is an area where many projects may contribute their own
generators making it difficuilt to be sure whether EMF or some other
project is to blame.

setOperationReflection and setRootExtendsClass are properties important
to OCL so I did a quick check but find no calls to
setOperationReflection in the OCL code base.

Projects that use OCL such as Acceleo or QVTo might just be associated
with the problem. Just possibly the JavaScript or even Xcore builders
might be 'helping'.

Set a breakpoint on setOperationReflection and see who it is.

Regards

Ed Willink

On 11/09/2013 14:19, Tom Brus wrote:
> Hi,
>
> I am running Ecore2GenModel -reload under jenkins as part of a tycho
> build under kepler.
> I discovered that some genmodels loose precious information during
> this action.
> I dug into the code and found this weird method in
> ModelImporterApplication:
>
> protected void adjustModelImporterAfterPrepare()
> {
> GenModel genModel = getModelImporter().getGenModel();
> if (genJDKLevel != null)
> {
> genModel.setComplianceLevel(genJDKLevel);
> }
> genModel.setImportOrganizing(importOrganizing);
> genModel.setOperationReflection(false);
> genModel.setRootExtendsClass("org.eclipse.emf.ecore.impl.EObjectImpl");
> // Subclasses may overwrite
> }
>
> The OperationReflection and RootExtendsClass fields are exactly the
> fields that I noticed were lost in the process.
>
> The model is first read correctly, then all the details are moved
> correctly to a new model and then, bang, some fields are overwritten
> with constant values. I am confused.
>
> Can someone deconfuse me?
>
> Tom Brus
>
> P.S. as a workaround I have put some code around the Ecore2GenModel
> that will preserve those field.

Report message to a moderator

Re: Ecore2GenModel crippling my genmodel, why? [message #1106752 is a reply to message #1106729]

Wed, 11 September 2013 14:00

Ed Merks

Messages: 33146
Registered: July 2009

Senior Member

Tom,

It looks like those changes were committed as part of
https://bugs.eclipse.org/bugs/show_bug.cgi?id=175282, where I was making
sure our generator tests still and produce the same results. Default
GenModel settings were changed and this code ensures that the
applications still end up with the same defaults as before. But I think
it's not quite right, i.e., I think specifically the last two (or
three?) settings should be guarded with if (!reload). Does that sound
right to you? Please open a bugzilla.

On 11/09/2013 3:19 PM, Tom Brus wrote:
> Hi,
>
> I am running Ecore2GenModel -reload under jenkins as part of a tycho
> build under kepler.
> I discovered that some genmodels loose precious information during
> this action.
> I dug into the code and found this weird method in
> ModelImporterApplication:
>
> protected void adjustModelImporterAfterPrepare()
> {
> GenModel genModel = getModelImporter().getGenModel();
> if (genJDKLevel != null)
> {
> genModel.setComplianceLevel(genJDKLevel);
> }
> genModel.setImportOrganizing(importOrganizing);
> genModel.setOperationReflection(false);
> genModel.setRootExtendsClass("org.eclipse.emf.ecore.impl.EObjectImpl");
> // Subclasses may overwrite
> }
>
> The OperationReflection and RootExtendsClass fields are exactly the
> fields that I noticed were lost in the process.
>
> The model is first read correctly, then all the details are moved
> correctly to a new model and then, bang, some fields are overwritten
> with constant values. I am confused.
>
> Can someone deconfuse me?
>
> Tom Brus
>
> P.S. as a workaround I have put some code around the Ecore2GenModel
> that will preserve those field.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Ecore2GenModel crippling my genmodel, why? [message #1106753 is a reply to message #1106742]

Wed, 11 September 2013 14:00

Tom Brus

Messages: 26
Registered: February 2011

Junior Member

Hi Ed (Willink),

That is exactly what I did:
I traced it down to the method given above (located in org.eclipse.emf.importer.ModelImporterApplication). It perfectly explains what happens. My problem is that I would like to know WHY someone wrote this method. Was it for his specific model? Is there a general reason why these properties should be forced this way?

We want to keep these properties in our genmodel. So either we have an unusual requirement that needs revisiting or the above routine is a bug that should either be removed or only called under certain conditions.

Hope someone can shed dome light...

Tom

[Updated on: Wed, 11 September 2013 14:04]

Report message to a moderator