Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [EMF] EMF-generated model code can't be compiled if model contains class called "Container&
[EMF] EMF-generated model code can't be compiled if model contains class called "Container& [message #1063797] Fri, 14 June 2013 09:33 Go to next message
Alex Lagarde is currently offline Alex LagardeFriend
Messages: 185
Registered: May 2010
Senior Member

Hi everyone,

although the issue https://bugs.eclipse.org/bugs/show_bug.cgi?id=262382
is marked as fixed, I still have an issue using EMF 2.8 to generate code.

In Mylyn Intent, I've got a Markup metamodel containing a "Container"
EClass.
Then another Intent metamodel has a containment reference returning an
instance of this "Container" EClass
https://github.com/eclipse/mylyn.docs.intent.main/blob/master/plugins/org.eclipse.mylyn.docs.intent.core/src-gen/org/eclipse/mylyn/docs/intent/core/document/descriptionunit/impl/DescriptionBlocImpl.java

As the Intent code is generated in CDO-Native mode, any Impl class
extends CDOObjectImpl which extends MinimalEObjectImpl, which has a
public static inner Class called "Container". So even if I import the
"Container" Eclass from markup, it is the inner class of
MinimalEObjectImpl which is considered.

To work-around this issue, I have to always use the fully-qualified name
for my "Container". But if I do so, when I re-generate a new method
without the qualified name is generated. So I had to mark the whole
Class as @generated NOT.

The work-around works, but it is not clean and according to what I
understood I should not have to do that since EMF 2.5.

Although not critical, the issue is quite annoying as it means that as
soon as you generate CDO-Native code, you cannot have an EClass named
"Container" without having to put @generated NOT annotations.

Am I doing something wrong here or should I reopen the issue?

Best regards,
Alex
Re: [EMF] EMF-generated model code can't be compiled if model contains class called "Contai [message #1063805 is a reply to message #1063797] Fri, 14 June 2013 10:22 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26285
Registered: July 2009
Senior Member
Alex,

So the problem appears to be in the following code in
org.eclipse.emf.codegen.ecore.genmodel.impl.GenClassImpl.addClassPsuedoImports()

public void addClassPsuedoImports()
{
GenModel genModel = getGenModel();
for (GenClass rootGenClass = this;;)
{
GenClass baseGenClass = rootGenClass.getBaseGenClass();
if (baseGenClass == null)
{
String rootExtendsClass =
rootGenClass.getGenModel().getRootExtendsClass();
if
("org.eclipse.emf.ecore.impl.MinimalEObjectImpl".equals(rootExtendsClass))
{
genModel.addPseudoImport("org.eclipse.emf.ecore.impl.MinimalEObjectImpl.Container");
}
else if
("org.eclipse.emf.ecore.impl.MinimalEObjectImpl$Container".equals(rootExtendsClass)
||
"org.eclipse.emf.ecore.impl.MinimalEObjectImpl$Container$Dynamic".equals(rootExtendsClass))
{
genModel.addPseudoImport("org.eclipse.emf.ecore.impl.MinimalEObjectImpl.Container");
genModel.addPseudoImport("org.eclipse.emf.ecore.impl.MinimalEObjectImpl.Container.Dynamic");
}
break;
}
else
{
rootGenClass = baseGenClass;
}
}
}

I.e., it knows nothing about CDO's specialized implementation class and
what nested interface/classes it makes visible that can cause
conflicts. I can't even rely on Java reflection to do a better job
because the specified class might exist only in the target platform, not
in the running IDE itself.

More comments below.


On 14/06/2013 11:33 AM, Alex Lagarde wrote:
> Hi everyone,
>
> although the issue
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=262382 is marked as
> fixed, I still have an issue using EMF 2.8 to generate code.
>
> In Mylyn Intent, I've got a Markup metamodel containing a "Container"
> EClass.
> Then another Intent metamodel has a containment reference returning an
> instance of this "Container" EClass
> https://github.com/eclipse/mylyn.docs.intent.main/blob/master/plugins/org.eclipse.mylyn.docs.intent.core/src-gen/org/eclipse/mylyn/docs/intent/core/document/descriptionunit/impl/DescriptionBlocImpl.java
>
> As the Intent code is generated in CDO-Native mode, any Impl class
> extends CDOObjectImpl which extends MinimalEObjectImpl, which has a
> public static inner Class called "Container". So even if I import the
> "Container" Eclass from markup, it is the inner class of
> MinimalEObjectImpl which is considered.
>
> To work-around this issue, I have to always use the fully-qualified
> name for my "Container". But if I do so, when I re-generate a new
> method without the qualified name is generated. So I had to mark the
> whole Class as @generated NOT.
That's ugly. You couldn't just mark the affected method(s)?
>
> The work-around works, but it is not clean and according to what I
> understood I should not have to do that since EMF 2.5.
>
> Although not critical, the issue is quite annoying as it means that as
> soon as you generate CDO-Native code, you cannot have an EClass named
> "Container" without having to put @generated NOT annotations.
Yes, that's kind of ugly.
>
> Am I doing something wrong here or should I reopen the issue?
Yes, please open a bugzilla. I'm not sure how to generalize this.
Perhaps yet another property for all the conflicting class names of the
root extends class...
>
> Best regards,
> Alex
Re: [EMF] EMF-generated model code can't be compiled if model contains class called "Contai [message #1063812 is a reply to message #1063805] Fri, 14 June 2013 11:08 Go to previous message
Alex Lagarde is currently offline Alex LagardeFriend
Messages: 185
Registered: May 2010
Senior Member

Hi Ed,

thanks a lot for your fast reply!

- "That's ugly. You couldn't just mark the affected method(s)?"
Nope, by marking just the methods as @generated NOT when the code is
generated for the Class it does not detect that there is already a
method setDescriptionBloc(Container newDescriptionBloc) and it generates
it again. I had to mark the whole class as @generated NOT to make sure
that I won't commit this new method by inadvertence.

- "Yes, please open a bugzilla. I'm not sure how to generalize this.
Perhaps yet another property for all the conflicting class names of the
root extends class..."
Done https://bugs.eclipse.org/bugs/show_bug.cgi?id=410802 . Let the
default priority, but maybe this could be considered as Major? I let you
decide :)

Thanks again,
Alex
Le 14/06/2013 12:22, Ed Merks a écrit :
> Alex,
>
> So the problem appears to be in the following code in
> org.eclipse.emf.codegen.ecore.genmodel.impl.GenClassImpl.addClassPsuedoImports()
>
>
> public void addClassPsuedoImports()
> {
> GenModel genModel = getGenModel();
> for (GenClass rootGenClass = this;;)
> {
> GenClass baseGenClass = rootGenClass.getBaseGenClass();
> if (baseGenClass == null)
> {
> String rootExtendsClass =
> rootGenClass.getGenModel().getRootExtendsClass();
> if
> ("org.eclipse.emf.ecore.impl.MinimalEObjectImpl".equals(rootExtendsClass))
> {
> genModel.addPseudoImport("org.eclipse.emf.ecore.impl.MinimalEObjectImpl.Container");
>
> }
> else if
> ("org.eclipse.emf.ecore.impl.MinimalEObjectImpl$Container".equals(rootExtendsClass)
> ||
> "org.eclipse.emf.ecore.impl.MinimalEObjectImpl$Container$Dynamic".equals(rootExtendsClass))
>
> {
> genModel.addPseudoImport("org.eclipse.emf.ecore.impl.MinimalEObjectImpl.Container");
>
> genModel.addPseudoImport("org.eclipse.emf.ecore.impl.MinimalEObjectImpl.Container.Dynamic");
>
> }
> break;
> }
> else
> {
> rootGenClass = baseGenClass;
> }
> }
> }
>
> I.e., it knows nothing about CDO's specialized implementation class and
> what nested interface/classes it makes visible that can cause
> conflicts. I can't even rely on Java reflection to do a better job
> because the specified class might exist only in the target platform, not
> in the running IDE itself.
>
> More comments below.
>
>
> On 14/06/2013 11:33 AM, Alex Lagarde wrote:
>> Hi everyone,
>>
>> although the issue
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=262382 is marked as
>> fixed, I still have an issue using EMF 2.8 to generate code.
>>
>> In Mylyn Intent, I've got a Markup metamodel containing a "Container"
>> EClass.
>> Then another Intent metamodel has a containment reference returning an
>> instance of this "Container" EClass
>> https://github.com/eclipse/mylyn.docs.intent.main/blob/master/plugins/org.eclipse.mylyn.docs.intent.core/src-gen/org/eclipse/mylyn/docs/intent/core/document/descriptionunit/impl/DescriptionBlocImpl.java
>>
>>
>> As the Intent code is generated in CDO-Native mode, any Impl class
>> extends CDOObjectImpl which extends MinimalEObjectImpl, which has a
>> public static inner Class called "Container". So even if I import the
>> "Container" Eclass from markup, it is the inner class of
>> MinimalEObjectImpl which is considered.
>>
>> To work-around this issue, I have to always use the fully-qualified
>> name for my "Container". But if I do so, when I re-generate a new
>> method without the qualified name is generated. So I had to mark the
>> whole Class as @generated NOT.
> That's ugly. You couldn't just mark the affected method(s)?
>>
>> The work-around works, but it is not clean and according to what I
>> understood I should not have to do that since EMF 2.5.
>>
>> Although not critical, the issue is quite annoying as it means that as
>> soon as you generate CDO-Native code, you cannot have an EClass named
>> "Container" without having to put @generated NOT annotations.
> Yes, that's kind of ugly.
>>
>> Am I doing something wrong here or should I reopen the issue?
> Yes, please open a bugzilla. I'm not sure how to generalize this.
> Perhaps yet another property for all the conflicting class names of the
> root extends class...
>>
>> Best regards,
>> Alex
>
Previous Topic:Programmatically sync EMF editors
Next Topic:Merging and VCS Best Practices
Goto Forum:
  


Current Time: Sat Dec 20 23:53:56 GMT 2014

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

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