Sven,
It's always hard to argue that a particular language is better than
another without being very specific about better from which
perspective. It's a little like arguing about which baby is prettier.
Much will be in the eye of the beholder. ;-) For example, the fact
that JET supports Java syntax can be great if you know Java and don't
want to learn yet another language but can be bad if you don't know
Java and don't want to learn yet another language.
Note that the JET2 work introduces a lot of capabilities not in JET,
such as taglib support:
http://www.eclipse.org/emft/projects/jet/
Sven Efftinge wrote:
I
think the main question is: "Why would we need another template
language?"
We already have three different languages for this purpose:
JET, MOFScript and Xpand
JET is indeed not the best template language (only Java type system
(not Ecore), no polymorhic template calls, simple expressions (Java),
etc.)
But Xpand and MOFScript are both much better and advanced than anything
I've seen so far (including Acceleo).
In addition Xpand is just one of several languages from the
openArchitectureWare language family. They are all based on the same
type system and on the same OCL _expression_ language.
Maybe we should do a more detailed feature comparism.
Of course one could use Acceleo (as well as JET, Xpand, MOFScript)
together with the ModelBus. The question is why should I use language X
in favor of language Y, as they all try to solve the same problems. And
the next question is, why should we add another template language to
the eclipse project?
I only can think of one reason (ignoring politics here ;-)):
It is a better language!
Acceleo isn't.
regards,
Sven
Etienne Juliot schrieb:
Hi,
From the eclipse modeling project page :
- Java Emitter Templates (JET) : provides code generation framework
& facilities that are used by EMF.
- Model Driven Development integration (MDDi) : produces an extensible
framework and exemplary tools dedicated to integration of modeling
tools in Eclipse.
Regarding MDDi, we can imagine the following schema :
----------------- -----------------
| external tool | | external tool |
| ----------- | | ----------- |
| model based | | text based |
----------------- -----------------
| |
| |
QVT Acceleo
| |
| |
-----------------------------------------
| ModelBus |
-----------------------------------------
|
|
-----------------------------------------
| EMF |
-----------------------------------------
|
|
JET
|
|
-----------------------------------------
| Eclipse infrastructure |
-----------------------------------------
So, Acceleo would be used by projects and products which aren't inside
Eclipse to create generative modules.
Theses externals tools can be in Java technology, but also in C, Perl,
PHP, Cobol ...
Basically, developers from these external tools won't be necessary
familiar with Java or JSP syntax. So it may be difficult for them to
create adapters for Mddi/eclipse integration.
Acceleo provides a minimalist syntax : only "if" and "for" are
provided. So it is quick to catch up with Acceleo and write a small
Mddi adapter if you are not a JSP or Java expert.
So the idea with Acceleo in Mddi is to ease the creation of glue with
non model based tools, and enabling non-Java expert to contribute
easily.
Sébastien Demathieu a écrit :
Hello all,
I agree that we need to make use of a code generation solution in MDDi
(to generate bus adapters from tool descriptors, for instance), like
many other Eclipse projects do.
There is a project in the Eclipse Modeling top-level project that
focuses on codegen: EMFT. It includes JET and the JET editor and I
would have look at these frameworks at a first stage. Other frameworks
from GMT may also provide alternatives although I do not know all of
these.
Given that we are all in the Modeling project, I think it is important
to leverage existing solutions rather than re-inventing the wheel.
As for Accello, I am wondering how the tool relates to JET (or other
Eclipse projects) and if it can provide a valuable contribution to the
Modeling project in a broader context.
Thanks,
Sébastien
|