|
|
|
|
|
| Re: Tips/Advices to change EMF code generator behaviours [message #1793522 is a reply to message #1793217] |
Thu, 09 August 2018 13:52   |
 Regent LArcheveque
Messages: 94
Registered: May 2010 |
Member |
|
|
Hi,
As indicated above, I created customs GenClassGeneratorAdapter and ImportManager classes and overrided ImportManager#getImportedName(String qualifiedName, boolean autoImport). I am trying to get the definition of the EClass associated to that qualifiedName. I digged into GenClass, EPackage, ECoreUtil but I found nothing. I presume the code generator maintains that kind of information somewhere. If you have some tips, that would be appreciated. Here is an overview of the code.
public class ApogyGenClassAdapter extends GenClassGeneratorAdapter {
public ApogyGenClassAdapter(GeneratorAdapterFactory generatorAdapterFactory) {
super(generatorAdapterFactory);
}
@Override
protected void createImportManager(String packageName, String className) {
importManager = new ImportManager(packageName, className) {
@Override
public String getImportedName(String qualifiedName, boolean autoImport) {
// Here are the elements on which we can dig into to figure out the
// associated EClass:
// -GenClass genClass = (GenClass) generatingObject;
// -String qualifiedName (e.g. org.eclipse.emf.ecore.EObject)
// -String this.packageName (e.g. org.eclipse.apogy)
// -String this.className (e.g. DummyClassnameImpl)
return super.getImportedName(qualifiedName, autoImport);
}
};
}
}
Regent ;-)
|
|
|
|
|
|
|
|
| Re: Tips/Advices to change EMF code generator behaviours [message #1794355 is a reply to message #1793217] |
Wed, 29 August 2018 13:37 |
Regent LArcheveque
Messages: 94
Registered: May 2010 |
Member |
|
|
Hi,
In the past few days, I have continued development. While I was completing the javadoc and the last tests, I realized that the Import Manager has stopped working. I decided to create an example from the bottom up. After 2 days of tests of all kinds, I can no longer operate the Import Manager. It seems that the getImportedName () I overloaded no longer plays its role. Yet everything worked perfectly. I'm sure it's a detail that is missing but I cannot figure it out. Here's the main artifacts.
1) TestGeneratorAdapterFactory
public class TestGeneratorAdapterFactory extends GenModelGeneratorAdapterFactory {
@Override
public Adapter createGenClassAdapter() {
if (genClassGeneratorAdapter == null) {
genClassGeneratorAdapter = new GenClassGeneratorAdapter(this) {
@Override
protected void createImportManager(String packageName, String className) {
importManager = new TestImportManager(packageName);
importManager.addMasterImport(packageName, className);
if (generatingObject != null) {
((GenBase) generatingObject).getGenModel().setImportManager(importManager);
}
}
};
}
return genClassGeneratorAdapter;
}
@Override
public Adapter createGenPackageAdapter() {
if (genPackageGeneratorAdapter == null) {
genPackageGeneratorAdapter = new GenPackageGeneratorAdapter(this) {
@Override
protected void createImportManager(String packageName, String className) {
importManager = new TestImportManager(packageName);
importManager.addMasterImport(packageName, className);
if (generatingObject != null) {
((GenBase) generatingObject).getGenModel().setImportManager(importManager);
}
}
};
}
return genPackageGeneratorAdapter;
}
@Override
public Adapter createGenModelAdapter() {
if (genModelGeneratorAdapter == null) {
genModelGeneratorAdapter = new GenModelGeneratorAdapter(this) {
@Override
protected void createImportManager(String packageName, String className) {
importManager = new TestImportManager(packageName);
importManager.addMasterImport(packageName, className);
if (generatingObject != null) {
((GenBase) generatingObject).getGenModel().setImportManager(importManager);
}
}
};
}
return genModelGeneratorAdapter;
}
public class TestImportManager extends ImportManager {
public TestImportManager(String compilationUnitPackage) {
super(compilationUnitPackage);
}
@Override
public String getImportedName(String qualifiedName, boolean autoImport) {
if (qualifiedName.equals("test.impl.AImpl")) {
return super.getImportedName("test.impl.ACustomImpl", autoImport);
} else {
return super.getImportedName(qualifiedName, autoImport);
}
}
};
}
2) test.xcore test sample
@GenModel(dynamicTemplates="false")
package test
class A{}
class B extends A{}
3) Resulting Class (AImpl should be ACustomImpl based on TestGeneratorAdapterFactory)
public class BImpl extends AImpl implements B {
protected BImpl() {
super();
}
@Override
protected EClass eStaticClass() {
return TestPackage.Literals.B;
}
} //BImpl
I put in attachment the codegen sample project (Eclipse host) and the codegen test project (Eclipse target).
Thanks in advance.
|
|
|
|
|
|
|
|
| Re: Tips/Advices to change EMF code generator behaviours [message #1794378 is a reply to message #1793217] |
Wed, 29 August 2018 19:23 |
Regent LArcheveque
Messages: 94
Registered: May 2010 |
Member |
|
|
Hi,
My colleague and pursued the investigation without any success. I modified a little the codegen to simplify the debugging. I tried different approaches in ImportManager#getImportedName(String, boolean) such as:
returnValue = super.getImportedName("test.impl.AImpl", autoImport);
returnValue = super.getImportedName("test.impl.ACustomImpl", autoImport);
shortNameToImportMap.put("AImpl", "test.impl.ACustomImpl");
addImport("test.impl.ACustomImpl");
returnValue = "ACustomImpl";
Despite the several permutations, no changes were conclusive.
IMPORTANT NOTE: At some point, and I don't know why, we noticed momentarily the proper desired change to be reflected in the target JDT editor then it switched back to the default and undesired behaviour. This happened for a while before stopping for a reason that I do not understand.
ORIGINAL: public class BImpl extends AImpl
INTERMEDIATE: public class BImpl extends ACustomImpl (change momentarily less than half a second)
FINAL: public class BImpl extends AImpl
If you generate the code for test.xcore, the custom codegen generate a log in the console. Pay attention to the last section:
TestImportManager(): Qualified Name = test.impl.BImpl, ECoreClass = B
getImportedName(): test.impl.AImpl
[color=red] getImportedName() === Customize the import for this one.[/color]
[color=red] getImportedName(): test.impl.AImpl >>> ACustomImpl[/color]
getImportedName(): test.B
getImportedName(): test.B >>> B
getImportedName(): org.eclipse.emf.ecore.EClass
getImportedName(): org.eclipse.emf.ecore.EClass >>> EClass
getImportedName(): test.TestPackage
getImportedName(): test.TestPackage >>> TestPackage
printMap(shortName, importName):
super => BImpl.super
EClass => org.eclipse.emf.ecore.EClass
B => test.B
[color=red]ACustomImpl => test.impl.ACustomImpl[/color]
BImpl => test.impl.BImpl
this => BImpl.this
TestPackage => test.TestPackage
printImports():
org.eclipse.emf.ecore.EClass
test.B
test.TestPackage
I put in attachment the latest version of the custom codegen and its sample. I added the target platform I used to launch the target and test the sample.
I followed the loophole example (https://github.com/mbarbero/emf-loophole) and the OCLInEcore code generator.
I hope this could lead you to an idea???
Thanks ;-)
|
|
|
|
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03029 seconds
Search
Help
Register
Login
Home
