Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [Texo] Status about feature "support code generation which generates separate source files"
[Texo] Status about feature "support code generation which generates separate source files" [message #795324] Fri, 10 February 2012 10:27 Go to next message
Benoit Cantin is currently offline Benoit Cantin
Messages: 34
Registered: January 2012
Member
Hi all,

On this page http://wiki.eclipse.org/Texo#Future_Topics you mention the feature "support code generation which generates separate source files which can be manually changed, so not following the @generated pattern used in standard EMF "

In some conditions, this is a must have. For example, lets imagine that a JPA annotated entity model was generated on an scm trunk (git master, or svn etc...), and that from that trunk a branch was created, in order to perform evolutions on this model.

If for a reason or another, the model has to be changed on the trunk, then Texo will be used to regenerate annotated entities, and that might change order of declarations in those annotated entity classes. If additionally, people working on the trunk change the content of methods annotated @generatedNOT, then the merge for those working on the branch will be a nightmare.

So can you tell me if something is started about that feature or not ? Is it planned ? One common solution is to create 2 classes for each entity, one extending the other. The extended class contains all the generated code. The extending class contains nothing more than manual code. But i am not sure that it covers all the use cases of texo.

[Updated on: Fri, 10 February 2012 10:45]

Report message to a moderator

Re: [Texo] Status about feature "support code generation which generates separate source fi [message #795381 is a reply to message #795324] Fri, 10 February 2012 12:04 Go to previous messageGo to next message
Martin Taal is currently offline Martin Taal
Messages: 5339
Registered: July 2009
Senior Member
Hi Benoit,
Nothing has been done for this feature. But I am kind of waiting for someone to need this, to add it. I am okay to also
support this generation-school-of-thought as it is a valid opinion (although I prefer the EMF-way myself).

The difficulty is not so much customizing in a derived class. If you have a flat inheritance structure then this can be
done now also with Texo (just create your subclass and customize one factory method). The 'problem' is in case of an
inheritance structure. Then this customize-class needs to be part of the inheritance structure.

Can you enter a bugzilla for it? Then I will pick it up from there.

gr. Martin

On 02/10/2012 11:27 AM, Benoit Cantin wrote:
> Hi all,
>
> On this page http://wiki.eclipse.org/Texo#Future_Topics you mention the feature "support code generation which generates
> separate source files which can be manually changed, so not following the @generated pattern used in standard EMF "
>
> In some conditions, this is a must have. For example, lets imagine that a JPA annotated entity model was generated on an
> scm trunk (git master, or svn etc...), and that from that trunk a branch was created, in order to perform evolutions on
> this model.
>
> If for a reason or another, the model has to be changed on the trunk, then Texo will be used to regenerate annotated
> entities, and that might change order of declarations in those annotated entity classes. If additionally, people working
> on the trunk change the content of methods annotated @generatedNOT, then the merge for those working on the branch will
> be a nightmare.
>
> So can you tell me if something is started about that feature or not ? Is it planned ? One common solution is to create
> 2 classes for each entity, one extending the other. The extended class contains all the generated code. The extending
> class contains nothing more than manual code. But i am sure that it covers all the use cases of texo.


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: [Texo] Status about feature "support code generation which generates separate source fi [message #795547 is a reply to message #795381] Fri, 10 February 2012 15:47 Go to previous messageGo to next message
Benoit Cantin is currently offline Benoit Cantin
Messages: 34
Registered: January 2012
Member
Hi Martin,

Here is my point of view both with and without inheritance, because I think that both can be handled the same way - at least when only JPA entities are generated.

Lets take an example : 2 entity classes B and C inheriting from an entity class A. Texo could generate something like this :

@MappedSuperclass
public abstract class BaseA {
    @Id
    public Long id;
    
    public String nameBaseA;
}


@Entity
// Inheritance mode according to annotation model
@Inheritance(strategy=InheritanceType.JOINED)
public class A extends BaseA {
    public String nameA;
}


@MappedSuperclass
public abstract class BaseB extends A {
    public String nameBaseB;
}


@Entity
public class B extends BaseB {
    public String nameB;
}


@MappedSuperclass
public abstract class BaseC extends A {
    public String nameBaseC;
}


@Entity
public class C extends BaseC {
    public String nameC;
}


(here attributes called *name in classes are optional, it is just to show how to work in all classes).

I suggest that Texo could generate classes A, B and C once for all. Those classes would be the ones in which the user would manually write his code. Those classes are annotated @Entity, because when the user will use his ORM tool, I guess that he will want to manipulate classes A, B and C, not BaseA, BaseB, and BaseC.

Now, Texo should also generate BaseA, BaseB, and BaseC. Those classes would always be generated. So that the user must not write anything inside. Because of how JPA supports inheritance, those classes have to be annotated @MappedSuperclass.

I tested this with Hibernate, and my schema is generated correctly. I have not gone much far (with relations in mapped supperclasses for example, does this work ?).

Texo would also have to propose an option for this, at package and class levels, because the user may not always want to use this mechanism. If the mechanism is disabled, then Texo should generate entities like it does today.

Well, I don't know how this can be integrated with all the stuff around Texo and JPA (orm.xml, factories relying on EMF, etc...).

This is an implementation proposal. Anyway, I am going to post this in a bugzilla.

Thanks for your time Smile

[Updated on: Fri, 10 February 2012 15:51]

Report message to a moderator

Re: [Texo] Status about feature "support code generation which generates separate sourc [message #795579 is a reply to message #795547] Fri, 10 February 2012 16:21 Go to previous messageGo to next message
Martin Taal is currently offline Martin Taal
Messages: 5339
Registered: July 2009
Senior Member
Hi Benoit,
Yes please copy this proposal in a bugzilla then we can discuss it further there!

gr. Martin

On 02/10/2012 04:47 PM, Benoit Cantin wrote:
> Hi Martin,
>
> Here is my point of view both with and without inheritance, because I think that both can be handled the same way - at
> least when only JPA entities are generated.
>
> Lets take an example : 2 entity classes B and C inheriting from an entity class A. Texo could generate something like
> this :
>
> @MappedSuperclass
> public abstract class BaseA {
> @Id
> public Long id;
> public String nameBaseA;
> }
>
>
>
> @Entity
> // Inheritance mode according to annotation model
> @Inheritance(strategy=InheritanceType.JOINED)
> public class A extends BaseA {
> public String nameA;
> }
>
>
>
> @MappedSuperclass
> public abstract class BaseB extends A {
> public String nameBaseB;
> }
>
>
>
> @Entity
> public class B extends BaseB {
> public String nameB;
> }
>
>
>
> @MappedSuperclass
> public abstract class BaseC extends A {
> public String nameBaseC;
> }
>
>
>
> @Entity
> public class C extends BaseC {
> public String nameC;
> }
>
>
> (here attributes called *name in classes are optional, it is just to show how to work in all classes).
>
> I suggest that Texo could generate classes A, B and C once for all. Those classes would be the ones in which the user
> would manually write his code. Those classes are annotated @Entity, because when the user will use his ORM tool, I guess
> that he will want to manipulate classes A, B and C, not BaseA, BaseB, and BaseC.
>
> Now, Texo should also generate BaseA, BaseB, and BaseC. Those classes would always be generated. So that the user must
> not write anything inside. Because of how JPA supports inheritance, those classes have to be annotated @MappedSuperclass.
>
> I tested this with Hibernate, and my schema is generated correctly. I have not gone much far (with relations in mapped
> supperclasses for example, does this work ?).
>
> Texo would also have to propose an option for this, at package and class levels, because the user may not always want to
> use this mechanism.
>
> Well, I don't know how this can be integrated with all the stuff around Texo and JPA (orm.xml, factories relying on EMF,
> etc...).
>
> This is an implementation proposal. Anyway, I am going to post this in a bugzilla.
>
> Thanks for your time :)


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: [Texo] Status about feature "support code generation which generates separate sourc [message #795590 is a reply to message #795579] Fri, 10 February 2012 16:45 Go to previous message
Benoit Cantin is currently offline Benoit Cantin
Messages: 34
Registered: January 2012
Member
Done : https://bugs.eclipse.org/bugs/show_bug.cgi?id=371256
Previous Topic:[MOVED][ecoretools] Problem creating opposite ERelation through the graphical editor
Next Topic:3rd Biannual Eclipse/OMG Workshop on March 25
Goto Forum:
  


Current Time: Sat Oct 25 13:30:17 GMT 2014

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

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