Home » Modeling » EMF » Generating code without EMF dependencies
| | |
| Re: Generating code without EMF dependencies [message #415144 is a reply to message #415143] |
Sat, 01 December 2007 17:25   |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Lukasz,
I know other folks have generated POJOs from Ecore, but I don't consider
that EMF's primary focus nor am I even keen on making it a secondary
focus. Maintaining support for all the existing patterns is already a
daunting task. In addition, it's almost inevitable that people will
need things like support for copying, notification of changes, XML
serialization, cross referencing, and so on, so I'm not terribly
motivated to provide POJO code generation because in the end I see it
has having little value. Also, I see dependencies on
org.eclipse.emf.common and org.eclipse.emf.ecore as extremely minor
given that huge dependency stack almost every any application has even
without two EMF plugins.
You're sure for example, that given an object, you won't need to
determine its container, that you don't need to persist your model as
XML or into a data base, that you won't need notification when changes
are made to the model, and that you won't benefit from change recording
that allows all changes to the model to be recorded and undone and
redone, or delete support that can find all references to an object to
excise them? Do you anticipate your application's footprint will be so
small that two EMF libraries are a cause for concern? All too often
I've seen people do what I call negative shopping, i.e., not realizing
that the features that come in the box are useful and will be needed
because it doesn't seem immediately apparent that it will be needed, and
then later needing them after all...
Lukasz Dywicki wrote:
> Hello Ed,
> The pure api is almost good. Almost because in code still exists
> references to methods declared in EMF types - eResolveProxy(),
> eNotificationRequired(), eNotify(), eStaticClass() etc.
> I don't need that at this moment. I would like generate only java
> beans (interfaces + implementation classes).
> EMF specific feature for me is inverse relationships with proxy.
> My .ecore file now is only a definition of domain layer used to build
> editor model. Who know, maybe in future i will use EMF to create
> editors? :)
>
>
>> What do you mean by "without EMF specific features"? Does this fit
>> the bill?
>>
>> 1.1 Recipe: Generating Pure API With No Visible EMF Dependencies
>>
>> < http://wiki.eclipse.org/EMF/Recipes#Recipe:_Generating_Pure_ API_With_No_Visible_EMF_Dependencies>
>>
>>
>>
>> Lukasz Dywicki wrote:
>>> Hello everyone!
>>> I would like to generate code from .ecore but without EMF specific
>>> features. Is there an posibility to do this?
>>>
>>> Regards,
>>> Luke
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Generating code without EMF dependencies [message #415146 is a reply to message #415145] |
Sat, 01 December 2007 23:10 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Rafael,
I'm not sure I agree that EMF is ever not a good fit, but most obviously
I'm completely biased. :-P It's even likely that this bias might cloud
my judgment. I'm pretty sure Martin Taal, the guy who does the awesome
EMFT Teneo work, has specialized the templates to product POJOs. Folks
interesting in this might want to contact him about that.
Rafael Chaves wrote:
> Lucasz,
>
> Basically what you are saying is that you want to use ECore as the
> metamodel for your models, but you want to generate code that does not
> rely on EMF's runtime capabilities. That is fine, there are many
> situations where the default model code generated by EMF is not a good
> fit. To generate code the way you want, you can use a template
> engine/language that can take ECore models as input. Velocity can do
> that (it will chew on any Java object), as can JET2:
>
> http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. jet.doc/tasks/usingJetWithEMF.xhtml
>
>
> HTH,
>
> Rafael
>
> Lukasz Dywicki wrote:
>> Hello everyone!
>> I would like to generate code from .ecore but without EMF specific
>> features. Is there an posibility to do this?
>>
>> Regards,
>> Luke
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Generating code without EMF dependencies [message #415148 is a reply to message #415146] |
Sun, 02 December 2007 10:37 |
Lukasz Dywicki
Messages: 34
Registered: July 2009 |
Member |
|
|
In my situation EMF is not fit. I am creating a model for editor. This
model will be stored in object database (db4o). Model should be a small
as they can be, because without this searching and object reading will
be slow. Now i save in database only simple javabeans (plus
java.io.File), i kick off from my model IResource because they was to
fat (after storing only one object with IResource reference db4o created
1MB file!).
> I'm not sure I agree that EMF is ever not a good fit, but most obviously
> I'm completely biased. :-P It's even likely that this bias might cloud
> my judgment. I'm pretty sure Martin Taal, the guy who does the awesome
> EMFT Teneo work, has specialized the templates to product POJOs. Folks
> interesting in this might want to contact him about that.
>
> Rafael Chaves wrote:
>> Lucasz,
>>
>> Basically what you are saying is that you want to use ECore as the
>> metamodel for your models, but you want to generate code that does not
>> rely on EMF's runtime capabilities. That is fine, there are many
>> situations where the default model code generated by EMF is not a good
>> fit. To generate code the way you want, you can use a template
>> engine/language that can take ECore models as input. Velocity can do
>> that (it will chew on any Java object), as can JET2:
>>
>> http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. jet.doc/tasks/usingJetWithEMF.xhtml
>>
>>
>> HTH,
>>
>> Rafael
>>
>> Lukasz Dywicki wrote:
>>> Hello everyone!
>>> I would like to generate code from .ecore but without EMF specific
>>> features. Is there an posibility to do this?
>>>
>>> Regards,
>>> Luke
|
|
|
| Re: Generating code without EMF dependencies [message #415149 is a reply to message #415148] |
Sun, 02 December 2007 12:59 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Lukasz,
I know nothing about db4o, but I imagine it might be possible that EMF
could be used to store any model into db4o using EMF reflection. Martin
Taal's EMFT work (Teneo) supports integration with Hibernate and JPOX
and the guys working on the EclipseLink project demonstrated support for
EMF persistence via their technology as well. Are you saying that db4o
could support persisting EMF objects because of links to Ecore (via
eClass) and things like that?
Maybe I ask how your editor will support undo? That's often very
difficult to implement...
Lukasz Dywicki wrote:
> In my situation EMF is not fit. I am creating a model for editor. This
> model will be stored in object database (db4o). Model should be a
> small as they can be, because without this searching and object
> reading will be slow. Now i save in database only simple javabeans
> (plus java.io.File), i kick off from my model IResource because they
> was to fat (after storing only one object with IResource reference
> db4o created 1MB file!).
>
>> I'm not sure I agree that EMF is ever not a good fit, but most
>> obviously I'm completely biased. :-P It's even likely that this
>> bias might cloud my judgment. I'm pretty sure Martin Taal, the guy
>> who does the awesome EMFT Teneo work, has specialized the templates
>> to product POJOs. Folks interesting in this might want to contact
>> him about that.
>>
>> Rafael Chaves wrote:
>>> Lucasz,
>>>
>>> Basically what you are saying is that you want to use ECore as the
>>> metamodel for your models, but you want to generate code that does
>>> not rely on EMF's runtime capabilities. That is fine, there are many
>>> situations where the default model code generated by EMF is not a
>>> good fit. To generate code the way you want, you can use a template
>>> engine/language that can take ECore models as input. Velocity can do
>>> that (it will chew on any Java object), as can JET2:
>>>
>>> http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. jet.doc/tasks/usingJetWithEMF.xhtml
>>>
>>>
>>> HTH,
>>>
>>> Rafael
>>>
>>> Lukasz Dywicki wrote:
>>>> Hello everyone!
>>>> I would like to generate code from .ecore but without EMF specific
>>>> features. Is there an posibility to do this?
>>>>
>>>> Regards,
>>>> Luke
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: Generating code without EMF dependencies [message #415167 is a reply to message #415166] |
Mon, 03 December 2007 16:27 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Lukasz,
Comments below.
Lukasz Dywicki wrote:
> Hello Ed,
> Db4o can store any object from any package (i've small problems with private classes).
> Object storing isn't problem, primarly problem is database size. When I had IResource instances in database file was to big.
Do you really mean IResource as in org.eclipse.core.resources.IResource
verses org.eclipse.emf.ecore.resource.Resource?
> When i stored only one object with IResource reference file had more than 1 MB.
>
> I going to minimize number of things stored in database eg EMF proxies - objects whose will be stored but whose aren't import for me.
>
Proxies are used primary for storing cross references and lazily
resolving them. I imagine in an object data base, you'd just be storing
references directly perhaps with no need for proxies.
> I've project builder whose know what was changed. With this informations I'm rebuild parts of model (graph nodes).
>
So I guess maybe your object data base has check pointing capabilities
that might allow you to implement undo by going back to an old state. I
wonder if that supports redo is or more like revert...
> When i searching objects db4o activate graph elements, small graphs = small access times (not many activations), big graph = long access times (many activations).
>
Eike Stepper is doing quite a bit of cool stuff that sounds a bit
similar. He's using InternalEObject.EStore support which allows all
data access to be redirected to any arbitrary data store. This allows
for the complete separation between the EObjects, which are more like
handles in this case, and the underlying storage that backs them. I
know some folks who have used this for lazy parsing for example.
In any case, I'm sure you know what's best for your applications...
> Regards,
> Luke
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 07:01:47 GMT 2024
Powered by FUDForum. Page generated in 0.03689 seconds |
] 
Search
Help
Register
Login
Home
