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  |
 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  |
Martin Taal
Messages: 5468
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 |
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 
[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 |
Martin Taal
Messages: 5468
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
|
|
| |
Goto Forum:
Current Time: Tue Apr 23 08:41:15 GMT 2024
Powered by FUDForum. Page generated in 0.03206 seconds |
] 
Search
Help
Register
Login
Home
