Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Tips/Advices to change EMF code generator behaviours(We are looking for tips to change slightly the way EMF generates the code to permit clear separation of custom code from generated-code using JET and EMF Code Generator.)
Tips/Advices to change EMF code generator behaviours [message #1793217] Wed, 01 August 2018 16:22 Go to next message
Regent LArcheveque is currently offline Regent LArchevequeFriend
Messages: 83
Registered: May 2010
Member
Hi,

We want to change slightly the way EMF generates the code to permit clear separation of custom code from generated-code using JET and EMF Code Generator. Here is an overview of the test that illustrates our issue.

BundleA XCore model
@GenModel(editDirectory="/org.eclipse.emf.test1.bundle_a.edit/src-gen")
package org.eclipse.emf.test1.bundle_a
class ClassA1{
	op void func() 
}
class ClassA2{
	op void func()
}

BundleA files
/src-gen/...impl/ClassA1Impl
/src-gen/...impl/Bundle_aFactoryImpl
/src-gen-custom/...impl/UserDefinedClassA2Impl (extends ClassA1Impl outside EMF).
/src-gen-custom/...impl/UserDefinedBundle_aFactoryImpl (extends Bundle_aFactoryImpl outside 
EMF).
plugin.xml (provide an factory_override that refers to UserDefinedBundle_aFactoryImpl

BundleB XCore model
@GenModel(editDirectory="/org.eclipse.emf.test1.bundle_b.edit/src-gen")
package org.eclipse.emf.test1.bundle_b
import org.eclipse.emf.test1.bundle_a.ClassA1
import org.eclipse.emf.test1.bundle_a.ClassA2
class ClassB1 extends ClassA1{ 
}
class ClassB2 extends ClassA2{ 
}

BundleB files
BundleB only contains generated code.

Default EMF Generator Behaviour
ClassA1Impl <- ClassB1Impl
ClassA2Impl <- ClassB2Impl

Desired EMF Generator Behaviour
ClassA1Impl <- ClassB1Impl
[color=skyblue]ClassA2Impl <- UserDefinedClassA2Impl <- ClassB2Impl[/color]

Problem Summary
In other words, if we detect a UserDefined class for a specific EMF generated class then we would like the inherited classes extend that UserDefined class. We would like similar behaviour with the ItemProviders generated in the .edit bundles.

Options
1) Use default EMF Code Generation and then start a new Builder that would analyse the EMF CompilationUnit and fix the inheritance with the AST. We think this option could work efficiently.

2) Inject required code/modified JET templates into the EMF Code Generator. We are not so sure with this option.

Workspace Sample
To import the attached sample
1) Import->General Existing Projects into Workspace
2) Select archive file: test_factory_override.zip

Thanks in advance for any tips and advices.

Thanks

Regent ;-)
Re: Tips/Advices to change EMF code generator behaviours [message #1793218 is a reply to message #1793217] Wed, 01 August 2018 16:49 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6112
Registered: July 2009
Senior Member
Hi

I would caution against changing / overriding the JET templates, because you may have to revisit your changes every time the official EMF templates evolve. But the approach should work.

You do not actually need a post-processor to change the code. You could take the approach of the OCL code generator. The OCL generator modifies the Ecore classes in-memory during the pre-process phase to define EAnnotations with Java bodies for the OCL-defined functionality. During the generate phase EMF emits the required Java function bodies. During the post-process phase the changes are reversed so that repeated genmodelling does not get confused.

See http://git.eclipse.org/c/ocl/org.eclipse.ocl.git/tree/examples/org.eclipse.ocl.examples.codegen/src/org/eclipse/ocl/examples/codegen/oclinecore

The generator approach has the advantage of no extra build steps and a better indication of the need to revisit the code for EMF evolution which is unlikely since only standard APIs are used.

Regards

Ed Willink
Re: Tips/Advices to change EMF code generator behaviours [message #1793223 is a reply to message #1793218] Wed, 01 August 2018 18:30 Go to previous messageGo to next message
Regent LArcheveque is currently offline Regent LArchevequeFriend
Messages: 83
Registered: May 2010
Member
Thanks Ed for the quick reply.

You raise a good point about the template. I'll take a look at OCL Generator as you proposed. At last, our problem is not about the method bodies but rather the class definition.

Default EMF Code Generation
public class ClassB2Impl extends ClassA2Impl implements ClassB2


Desired EMF Code Generation
public class ClassB2Impl extends UserDefinedClassA2Impl implements ClassB2
Re: Tips/Advices to change EMF code generator behaviours [message #1793264 is a reply to message #1793223] Thu, 02 August 2018 11:30 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 29653
Registered: July 2009
Senior Member
It seems to me that Xtext somehow supports this "generation gap" approach, but I'm not sure of the details,e.g., JvmIdentifiableElementImplCustom. I also remember someone from Obeo asking about it as well. I think they just used the trick of using the import manager to automatically redirect the imported name of the original expected to the intermediate class replacement/override name. I.e., whenever you're asked to import a qualified name, you could redirect to the custom replacement/override.
Re: Tips/Advices to change EMF code generator behaviours [message #1793373 is a reply to message #1793264] Mon, 06 August 2018 19:23 Go to previous messageGo to next message
Regent LArcheveque is currently offline Regent LArchevequeFriend
Messages: 83
Registered: May 2010
Member
Thanks Ed. I used the approach you proposed and it works. It is too simple!!!!

Regent ;-)
Re: Tips/Advices to change EMF code generator behaviours [message #1793522 is a reply to message #1793217] Thu, 09 August 2018 13:52 Go to previous messageGo to next message
Regent LArcheveque is currently offline Regent LArchevequeFriend
Messages: 83
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 #1793526 is a reply to message #1793522] Thu, 09 August 2018 14:48 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6112
Registered: July 2009
Senior Member
Hi

Try GenClass.getEcoreClass().

Regards

Ed Willink
Re: Tips/Advices to change EMF code generator behaviours [message #1793529 is a reply to message #1793526] Thu, 09 August 2018 15:20 Go to previous messageGo to next message
Regent LArcheveque is currently offline Regent LArchevequeFriend
Messages: 83
Registered: May 2010
Member
Hi Ed,
I tried to go through GenClass.getEcoreClass() without success. In my example, GenClass genClass = (GenClass) generatingObject refers to org.eclipse.apogy.DummyClassname EClass and the qualified name refers to something like (package_name.Class1). I omitted to mention the qualified name that causes problems are the ones that refer to EClass installed in bundles. I do not have trouble with the ones in the host workspace. The idea I have now is simply to simply look at the registered EPackage and extract all the installed EClass. Then I could get the properties of the EClass specified by the qualifiedName. I know we could have more than one EClass with the same fully qualified name in different bundles.

As you mention, I am pretty sure the solution is through GenClass.getECoreClass() and then dig into the structure and get a reference to the EClass. Another point that I could be exploited, I expect the qualified name EClass to be a SupertypeEClass of GenClass.getECoreClass().

I do not know if I am clear enough. A bit complicated to explain.

I continue my search.

Thanks ;-)
Re: Tips/Advices to change EMF code generator behaviours [message #1793533 is a reply to message #1793529] Thu, 09 August 2018 16:17 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6112
Registered: July 2009
Senior Member
Hi

Sorry, I don't understand at all.

If you don't have a GenClass, then you may have do do a search through GenPackages, but with a GenClass it should give the EClass. I don't understnad why you dont like the EClass. You suggest multiple bundles which may indicate a metamodel schizophrenia which seems unlikely for your problem.

You need to find out why GenClass.getEcoreClass gives the 'wrong' answer rather than find a different way of computing the 'right' answer.

Are you sure you are not being confused by an unresolved proxy? Have you checked ALL the ResourceSet.getResources().getErrors() ?

Regards

Ed Willink
Re: Tips/Advices to change EMF code generator behaviours [message #1793535 is a reply to message #1793533] Thu, 09 August 2018 16:46 Go to previous messageGo to next message
Regent LArcheveque is currently offline Regent LArchevequeFriend
Messages: 83
Registered: May 2010
Member
I just got it. I am able to extract all the information that I required from the GenClass.getECoreClass(). It works exactly as you mentioned and as expected. The reason of my problem was related to the debugging of a wrong EClass (in my test case).

I really like the way it is done. The implementation follows the spirit of EMF code generation.

Thanks Ed.
Re: Tips/Advices to change EMF code generator behaviours [message #1793538 is a reply to message #1793535] Thu, 09 August 2018 17:34 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6112
Registered: July 2009
Senior Member
Hi

Easy done. Thanks for providing the 'solution' for others.

Regards

Ed Willink
Re: Tips/Advices to change EMF code generator behaviours [message #1794355 is a reply to message #1793217] Wed, 29 August 2018 13:37 Go to previous messageGo to next message
Regent LArcheveque is currently offline Regent LArchevequeFriend
Messages: 83
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 #1794356 is a reply to message #1794355] Wed, 29 August 2018 13:38 Go to previous messageGo to next message
Regent LArcheveque is currently offline Regent LArchevequeFriend
Messages: 83
Registered: May 2010
Member
I use Photon 4.8-SDK.
Re: Tips/Advices to change EMF code generator behaviours [message #1794359 is a reply to message #1794356] Wed, 29 August 2018 14:42 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 29653
Registered: July 2009
Senior Member
Sorry, I won't have time to look closer today, but make sure that in org.eclipse.emf.codegen.ecore.genmodel.impl.GenModelImpl.getImportedName(String) it's really using your specialized ImportManager, and if not, find out how is calling org.eclipse.emf.codegen.ecore.genmodel.impl.GenModelImpl.setImportManager(ImportManager) with a different instance from the one you are hoping to use.
Re: Tips/Advices to change EMF code generator behaviours [message #1794362 is a reply to message #1794359] Wed, 29 August 2018 14:48 Go to previous messageGo to next message
Regent LArcheveque is currently offline Regent LArchevequeFriend
Messages: 83
Registered: May 2010
Member
It is really my custom ImportManager that is being called.
Thanks Ed.
Re: Tips/Advices to change EMF code generator behaviours [message #1794370 is a reply to message #1794362] Wed, 29 August 2018 16:18 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 29653
Registered: July 2009
Senior Member
That suggests your method is being called, but not for that class name? See what's happening in org.eclipse.emf.codegen.ecore.genmodel.impl.GenClassImpl.getClassExtends(). Surely that's being called and you just suggested it's calling you specialized importer too...
Re: Tips/Advices to change EMF code generator behaviours [message #1794373 is a reply to message #1794370] Wed, 29 August 2018 16:26 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6112
Registered: July 2009
Senior Member
Hi

When developing the OCL code generators, I recall a few miraculous things happening / not-happening. In particular you used to be able to get the wrong JET templates. IIRC a bug was fixed for this about 6 months ago.

I recommend putting in a few debug console output statements that clearly identify which software sub-system you are using from where and when.

Regards

Ed Willink
Re: Tips/Advices to change EMF code generator behaviours [message #1794378 is a reply to message #1793217] Wed, 29 August 2018 19:23 Go to previous messageGo to next message
Regent LArcheveque is currently offline Regent LArchevequeFriend
Messages: 83
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 ;-)
Re: Tips/Advices to change EMF code generator behaviours [message #1794380 is a reply to message #1794378] Wed, 29 August 2018 19:53 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6112
Registered: July 2009
Senior Member
Hi

The momentary change suggests you have two code generators at work. Yours produced the wanted change, then a standard produces the original text again.

You really must instrument all relevant subsystems to detect what is going on when and why and where.

The two generators may be two 'builders' or one builder with too many non-orthogonal GenModelGeneratorAdapterFactory instances.

Regards

Ed Willink
Re: Tips/Advices to change EMF code generator behaviours [message #1794381 is a reply to message #1794380] Wed, 29 August 2018 20:19 Go to previous messageGo to next message
Regent LArcheveque is currently offline Regent LArchevequeFriend
Messages: 83
Registered: May 2010
Member
Hi Ed,

I think you got it. I just checked the target plugins-registry (see picture). And there are 2 factories. But CustomGeneratorAdapterFactory extends GenModelGeneratorAdapterFactory. So I need both plugins. So what is the proper way to disable the GenModelGeneratorAdapterFactory. Should I use the adapter extension instead of the adapterFactory extension instead. I presume yes.

Thanks
Re: Tips/Advices to change EMF code generator behaviours [message #1794382 is a reply to message #1793217] Wed, 29 August 2018 20:37 Go to previous messageGo to next message
Regent LArcheveque is currently offline Regent LArchevequeFriend
Messages: 83
Registered: May 2010
Member
Sorry to ask.

What should be the model class for the following? Should I have my own tag? I am not sure.
<extension point="org.eclipse.emf.codegen.ecore.generatorAdapters">
<adapter
   class="codegen.CustomGenClassGeneratorAdapter"
   modelClass="????"
   modelPackage="http://www.eclipse.org/emf/2002/GenModel">
</adapter>
</extension>
Re: Tips/Advices to change EMF code generator behaviours [message #1794395 is a reply to message #1794382] Thu, 30 August 2018 07:29 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6112
Registered: July 2009
Senior Member
Hi

It depends what you're doing.

If you are providing facilities for your own closed purposes, e.g. invoked from JUnit tests or MWE2 scripts, just unregister the standard EMF generator and register your derived enhancements.

If, like the Eclipse OCL generator, your facilities are for all users at all times, you must make sure that you minimize impact on existing users. and is scaleable so that YourBetterEMF can coexist with MyBetterEMF. Displacing the standard EMF registrations is therefore a no-no. The Eclipse OCL generator is an additional generator that only reacts when requested by appropriate GenAnnotation/EAnnotation elements. You can see that OCLinEcoreGeneratorAdapterFactory returns null for GenClass/GenEnum/GenPackage. Only the GenModel support has the pre/post generate functionality to reify the embedded OCL as Java body EAnnotations for the standard GenClass generator to process during the standard generate phase.

(Reviewing OCLinEcoreGeneratorAdapterFactory, it would appear that inheriting from GenModelGeneratorAdapterFactory to get a free GeneratorAdapterFactory implementation is unhelpful. It would be more obvious to inherit from GenModelAdapterFactory directly and re-implement the four trivial GeneratorAdapterFactory methods.)

Regards

Ed Willink
Re: Tips/Advices to change EMF code generator behaviours [message #1794422 is a reply to message #1794395] Thu, 30 August 2018 12:12 Go to previous messageGo to next message
Regent LArcheveque is currently offline Regent LArchevequeFriend
Messages: 83
Registered: May 2010
Member
Hi Ed,

thank you for your time and your support. It is really appreciated. My case is really similar to your case. Our new Eclipse project (https://projects.eclipse.org/projects/technology.apogy) is entirely based on EMF. Currently our repo is on bitbucket (https://bitbucket.org/apogy/ca.gc.asc_csa.apogy/src/eclipse/) (branch eclipse, tools/org.eclipse.apogy.common.emf.codegen). This branch is not working yet and it will be transferred to eclipse repo as soon as the generator is fixed.
To fulfil our requirements, we require custom code. 95% of the time is to implement the operations. We want to instrument the .xcore to indicate if classes have custom code. We created these new EMF annotations:

1) @Apogy(hasCustomCode=<boolean>)
If true, the Apogy Generator will slightly adjust the generated package factory and generated classes.
1a) Factory#create%s() methods
public A createA() {
     AImpl a = new A<Custom>Impl();
     return a;
}

1b) Class extending classes with custom code.
public class BImpl extends A<Custom>Impl implements B


2) @Apogy(hasItemProvider=<boolean>)
Same approach for the itemProviders

3) @Apogy(isSingleton=<boolean>)
Create a singleton pattern using jet template (https://bitbucket.org/apogy/ca.gc.asc_csa.apogy/src/eclipse/tools/org.eclipse.apogy.common.emf.codegen/templates/model/Class/insert.javajetinc). This one still work because it uses the default jet template entry point mechanism.

The main advantages of this approach:
1) Custom code clearly separated from the generated code.
2) User metamodel (*.xcore) contains all the information about the class inheritance and structure. Eventually, it would be possible to the ECore diagram to render this information and shows custom classes and singleton classes.

Before the double Generator factory registrations, everything was working perfectly. Inheritance from external metamodel was working also. I think I got simply lucky with the sequence of execution of my generator factory and the default EMF generator factory.

I would like to go with the OCL approach as your proposed. In fact, I may like to propose such additions into the default EMF generator if the end behaviour looks good. I think this approach really address the generation gap pattern. I do not pretend it is a final version but I believe the concept is there and works well.

In org.eclipse.ocl.examples.codegen (v. 2.4.0.v20180611-1119), I noticed there are 2 registered adapter factories in the plugin.xml.
  <extension point="org.eclipse.emf.codegen.ecore.generatorAdapters">
     <adapterFactory class="org.eclipse.ocl.examples.codegen.oclinecore.OCLinEcoreGeneratorAdapterFactory"/>
     <adapterFactory modelPackage="http://www.eclipse.org/uml2/2.2.0/GenModel" class="org.eclipse.ocl.examples.codegen.oclinecore.OCLinEcoreGeneratorAdapterFactory"/>
  </extension>

Is it normal?

;-)
Re: Tips/Advices to change EMF code generator behaviours [message #1794423 is a reply to message #1794422] Thu, 30 August 2018 12:15 Go to previous messageGo to next message
Regent LArcheveque is currently offline Regent LArchevequeFriend
Messages: 83
Registered: May 2010
Member
Oupps, JET template link was wrong. Here is the good one https://bitbucket.org/apogy/ca.gc.asc_csa.apogy/src/eclipse/tools/org.eclipse.apogy.common.emf.codegen/templates/model/Class/.
;-)
Re: Tips/Advices to change EMF code generator behaviours [message #1794425 is a reply to message #1794423] Thu, 30 August 2018 13:15 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6112
Registered: July 2009
Senior Member
Hi

The two registrations ensure the OCL enhanced generator is used by the default http://www.eclipse.org/emf/2002/GenModel and by the http://www.eclipse.org/uml2/2.2.0/GenModel. You only need the UML registration if you want your enhancements to apply when users generate Java code from UML models.

(The UML project made the design decision to introduce a new namespace for a new overriding generator rather than use annotations to extend the standard EMF generator. Without a contrasting implementation of the alternative approach, it remains an open issue as to whether this was a good design decision.)

Regards

Ed Willink
Re: Tips/Advices to change EMF code generator behaviours [message #1794451 is a reply to message #1794425] Thu, 30 August 2018 18:13 Go to previous messageGo to next message
Regent LArcheveque is currently offline Regent LArchevequeFriend
Messages: 83
Registered: May 2010
Member
Hi Ed,

sorry to bother you again. I am still debugging. Would it be better to use the following to inject custom adapters? This way my custom adapter would (what I think) injected in the default EMF/XCore Generator org.eclipse.emf.codegen.ecore.genmodel.generator.GenModelGeneratorAdapterFactory. I dig into the org.eclipse.emf.codegen.ecore plugins to find out what should be the modelClass.

<extension point="org.eclipse.emf.codegen.ecore.generatorAdapters">
<adapter
   class="codegen.CustomGenClassGeneratorAdapter"
   modelClass="????"
   modelPackage="http://www.eclipse.org/emf/2002/GenModel">
</adapter>
</extension>
Re: Tips/Advices to change EMF code generator behaviours [message #1794452 is a reply to message #1794451] Thu, 30 August 2018 18:45 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6112
Registered: July 2009
Senior Member
Hi

No idea. I don't use modelClass. I might guess that it is something to do with the more general AdapterFactory that doesn't really seem relevant for the generator usage. Ed M may enlighten us.

Regards

Ed Willink
Re: Tips/Advices to change EMF code generator behaviours [message #1794466 is a reply to message #1794452] Fri, 31 August 2018 04:35 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 29653
Registered: July 2009
Senior Member
It's the name of the EClass in the EPackage referenced by the modelPackage attribute for which the class is the registered adapter, as used in org.eclipse.emf.codegen.ecore.CodeGenEcorePlugin.GeneratorAdaptersRegistryReader.GenericDescriptor.AdapterFactory.createAdapter(Notifier).
Previous Topic:[CDO] CDOStoreUnorderedEList invalidates index of RemoveCommand during undo
Next Topic:[EMF Forms] ViewModel testing
Goto Forum:
  


Current Time: Mon Nov 19 04:42:04 GMT 2018

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

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

Back to the top