Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Generation gap pattern and EcoreGenerator
Generation gap pattern and EcoreGenerator [message #758652] Thu, 24 November 2011 06:20 Go to next message
Xavier Seignard is currently offline Xavier SeignardFriend
Messages: 52
Registered: June 2010
Member
Hello,
Since I prefer writting custom code in separated classes rather than in the EMF model code, I'm trying the method described there : http://www.eclipsecon.org/2011/sessions/?page=sessions&id=2253

But I have some questions :
- I tried the sample on github and it seems that the directory cleaner is not executed ? (see the mwe2 log there :
https://gist.github.com/1390741)
- What if I want to customize the name of the custom classes? (I don't like the suffixed ones by Custom)
- In my own project custom code is not generated? (here is my mwe2 file : https://gist.github.com/1390746)

Still, it seems a good approach when you deal with some custom code.

And is there any drawbacks we should be aware of?

Kind regards,

Xavier

[Updated on: Thu, 24 November 2011 06:21]

Report message to a moderator

Re: Generation gap pattern and EcoreGenerator [message #758661 is a reply to message #758652] Thu, 24 November 2011 07:03 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14665
Registered: July 2009
Senior Member
Hi,

(1) have no idea why
(2) you may overwrite org.eclipse.emf.mwe2.ecore.EcoreGenerator.mapper
(3) dont you simply drop the manual created classes yourself and they get merged into the generated factories and stuff?

~Christian


Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Generation gap pattern and EcoreGenerator [message #758662 is a reply to message #758661] Thu, 24 November 2011 07:20 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14665
Registered: July 2009
Senior Member
hmmm i just tried (2) and it creates stubs

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Generation gap pattern and EcoreGenerator [message #758704 is a reply to message #758652] Thu, 24 November 2011 10:28 Go to previous message
Moritz Eysholdt is currently offline Moritz EysholdtFriend
Messages: 161
Registered: July 2009
Location: Kiel, Germany
Senior Member
Hi Xavier,

(answers inline)

> Since I prefer writing custom in separated classes rather than in the
> EMF model code, I'm trying the method described there :
> http://www.eclipsecon.org/2011/sessions/?page=sessions&id=2253

nice!

> But I have some questions : - I tried the sample on github and it seems
> that the directory cleaner is not executed ? (see the mwe2 log there :
> https://gist.github.com/1390741)

hm, could it be that the directory cleaner is configures for the wrong
directory?

What you might try is to set a breakpoint in
org.eclipse.emf.mwe.utils.DirectoryCleaner.invokeInternal(...) and
org.eclipse.emf.mwe.utils.DirectoryCleaner.checkConfigurationInternal(...)

Then launch the MWE2-Workflow via "Debug As...".

> - What if I want to customize the name of the custom classes? (I don't
> like the suffixed ones by Custom)

You'll have to subclass org.eclipse.emf.mwe2.ecore.EcoreGenerator and
override getTypeMapper(). getTypeMapper() returns an object that is
responsible for mapping EMF-names (e.g. FooBarImpl) to names of "custom"
classes (e.g. FooBarImplCustom). You can implement any mapping logic you
want. In your MWE2-Workflow, your subclass replaces the EcoreGenerator.

> - In my own project custom code is not generated? (here is my mwe2 file
> : https://gist.github.com/1390746)

true ;) It's not generated by default because we assume that not every
class from an EMF model will have a Custom-Class. Therefore, generating
stubs for all classes would kinda pollute the project. You can have
custom classes generated when you set

EcoreGenerator { generateCustomClasses = true }

in your workflow.

> Still, it seems a good approach when you deal with some custom code.

> And is there any drawbacks we should be aware of?

Yes, there is one thing you should have in mind when overriding Methods:
Since EMF supports multiple inheritance and Java does not, not all
super-classes declared on the EMF side will be actual super-classes on
the Java-Class-Side (only on the Java-Interface side).

regards,
Moritz
Previous Topic:[Xbase] extending scope for XVariableDeclaration
Next Topic:[Xtend 2.1]Setting a default output path for the code generator
Goto Forum:
  


Current Time: Thu Apr 25 16:35:20 GMT 2024

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

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

Back to the top