[News.eclipse.technology.mddi] Re: Accelo

["Joel Cheuoua" <jcheuoua@xxxxxxxxx>]

Hi Sven,

I'm jumping into the discussion just to give my $0.02 if useful at all.

"Sven Efftinge" <sven@xxxxxxxxxxx> wrote in message 
news:e6h2h0$c7k$1@xxxxxxxxxxxxxxxxxxxx
> Hi Ed,
>
> Ed Merks schrieb:
>> 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.
>
>
> And it is bad, if you try to do a lot of model navigation (which is 
> usually the case within generators and transformers). Additionally JET 
> relies on Java's type system not on EMF's (Ecore), what I cannot 
> understand as you've invented it... (And it's great!)
>

I think you're making exactly Ed's point here : you can perfectely navigate 
in the model ... using java. And yes Ecore is great ;) but I don't see why 
accessing it with its java implementation is very different than accessing 
it with yet another language. Wetter you're using java, ocl or any other 
language, navigating on Ecore is relying on Ecore.

For java lovers (like me :)) this is just perfect. I don't want to use any 
other ocl-like langage for that. OCL is fine, but I prefer java. Besides, 
this makes JET templates ready for accepting just any java realized meta 
data schemes, not only Ecore. Science-fiction example : If you decide to 
have a complete EMOF metamodel implementation that is reflective and 
realized in java (another hot issue isn't it ? ;) ) or Realistic example : 
even simply plain java objects, with metadata stored into hashmaps or 
accessible through java 5 annotations ... then you can still use JET 
templates for the code generation.

>
>>
>> Note that the JET2 work introduces a lot of capabilities not in JET, such 
>> as taglib support:
>>
>>     http://www.eclipse.org/emft/projects/jet/
>
>
> Yes, I've seen it and there are definitely some promising ideas in JET2, 
> but I really miss integration of EMFT's OCL expressions (or something 
> similar) and therefore support for dynamic EMF models.
> But we already talked about this in the EMF newsgroup (thread "Template 
> Language")
>

Indeed, this is again OCL vs. Java. And I can perfectly understand why you 
miss this OCL integration. I just wanted to point out the fact that as Ed 
said, some prefer java some else don't, and I'm one of the people that 
prefer java ...
What I see really missing in JET (I don't see it even in JET2) is templates 
overriding.
There are ways to do that but they are not so convenient as you need to 
define the extension points in the master templates beforehands.

> And, yes, you are right with that it's hard to argue this or that language 
> is better or not. But I wanted to direct the attention to what we already 
> have before adding another solution for the same problem to the EMP.
>

I fully agree with you on that :)

Cheers,

Joel.
> regards,
> Sven
>
>
>>
>>
>> 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
>>>>>
>>>>>
>>