Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Generate Ecore facade model from POJO API
Generate Ecore facade model from POJO API [message #659976] Wed, 16 March 2011 12:58
Hallvard Traetteberg is currently offline Hallvard TraettebergFriend
Messages: 672
Registered: July 2009
Location: Trondheim, Norway
Senior Member

I'm working on automating the creation of an EMF Facade for POJOs. The
idea is to operate on EMF objects and have it automatically sync the
corresponding POJOs. With such an EMF Facade, you can use existing EMF
tools, like the generic editor, for (implicitly) manipulating POJOs.

To make this work, the standard EMF change notifications must be
"translated" to sequences of methods calls on the POJO's API. E.g. a SET
change to the "child" feature of a Parent class, could result in a call
the Parent's setChild method, and similiar for ADD and REMOVE notifications.

Obviously, the translation cannot be fully automated, but I think you
can come fairly close by recognizing patterns in the API and guessing
both the corresponding Ecore model and the translation. E.g. if the
Parent POJO has Child getChild() and void setChild(Child) methods, we
can guess that the corresponding EMF class MParent should have a child
feature of the type MChild with upper bound 1. And for such a case, the
code for reacting to change notifications will be fairly boilerplate. In
some sense, this is the reverse of what Texo is doing: Instead of
generating the POJO APIs based on method patterns, we want to recognize
the API pattern and then generate the code for building the POJO
instances and updating them when the EObjects change.

The method of course requires the use of patterns in the POJO API, and
standard patterns, like those used by Texo, should be supported. It
should also be relatively easy to add new patterns, like SWT's use of
constructors with container and stylebits arguments. (In fact, the goal
(and initial motivation) is to cover (most parts of) SWT, so EMF can be
used for manipulating SWT UI designs. This should give a model that is
far closer to SWT (for good or bad) and with better coverage than TM
(part of e4) without (too) much hand-written code (apart from the

Now finally a question: Has anyone done something similar? What
technologies can be used for supporting part of the process (like
MoDisco for pattern discovery and Acceleo for code generation)?

Previous Topic:[CDO] Win7 DbStore starts OK but CDO Explorer cannot connect
Next Topic:[CDO] Can't get CDO Objectivity adapter running on Linux
Goto Forum:

Current Time: Sun May 31 21:14:59 GMT 2020

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

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

Back to the top