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  |
|
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  |
 Ed Merks
Messages: 33137
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| 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 |
|
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
>
|
|
|
Goto Forum:
Current Time: Sat Apr 20 00:14:19 GMT 2024
Powered by FUDForum. Page generated in 0.04254 seconds |
] 
Search
Help
Register
Login
Home
