[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.tools.emf] Re: Suppress EMF Types=true, Root Extends Class="", Root Extends Interface=""

Michael,

See answers, below.

Frank

Michael Vorburger wrote:

> Hello,
>
> I am looking at EMF (2.0.0) to generate code, and would like "to use
> standard Java, rather than EMF, collection and object types for features and
> operations". I have found a (new?) boolean option "Suppress EMF Types" in
> the genmodel properties which is set to true, and a "Root Extends Class" and
> a "Root Extends Interface" both of which I set to empty strings, and
> experimented with it, but...have some issues, like:

The intent of these new options is to allow you to create interfaces without any
EMF dependencies. As it says in the release notes, however, this work is
preliminary and still subject to change. Setting Root Extends Interface to an
empty strings is fine, but Root Extends Class will need to be some proper EMF
implementation class to make all the generated patterns hang together.

>
>
> *) The Impl classes still uses protected EList xyz. I want that to be List,
> too, just like on the interface now. (In fact, ideally I would actually like
> Many=True attributes it to be Collection or Set, not List, anyway, but
> setting Ordered to false doesn't seem to do that?)

We plan to support Ordered=false, but just haven't gotten to that yet. It would
only affect the type in the interface, however. The generated collections in the
implementation classes would still be one of the EMF implementation classes.

>
>
> *) The Impl classes have got tons of compile time errors, because I set
> "Root Extends Class" to empty, I want to inherit from java.lang.Object, not
> from org.eclipse.emf.ecore.impl.EObjectImpl, I don't want notification nor
> other EObject features, how to disable that?

As I said above, you can't make Root Extends Class empty. There is a new base
class of EObjectImpl, BasicEObjectImpl, which you can use, if you don't plan to
use notification, etc., and don't want to space overhead in your objects.

>
>
> If that's not possible / not the intended usage, I guess I'd have to define
> my own templates, correct?

That's right.

> Well, how? ;) I am aware of
> http://www.eclipse.org/articles/Article-JET/jet_tutorial1.html and
> http://www.eclipse.org/articles/Article-JET2/jet_tutorial2.html, but haven't
> actually tried it yet, is that still about right for 2.0.0?

Yes, nothing in JET has changed in 2.0.0.

> Noticed a New
> Java Emitter Template/Convert Projects to JET Projects, that replaces Add
> JET Nature, else also the same? What are the genmodel properties "Dynamic
> Templates", "Template Directory" etc. used for?

If you customize templates, you put your version into the "Template Directory"
and you need to set "Dynamic Templates" to true, so that the generator will pick
up your modified templates instead of using static precompiled default
templates. If you can get your hands on a copy of the EMF book, it will help you
understand all of this.

>
>
> Thank you very much,
> Michael