Eclipse Community Forums: EMF » Reference Model A classes in Model B without regenerating Model A

Home » Modeling » EMF » Reference Model A classes in Model B without regenerating Model A

Reference Model A classes in Model B without regenerating Model A [message #1803209]

Mon, 25 February 2019 05:48

Eclipse User

I am trying to reference an ecore Model A in another ecore Model B.
A class in Model A is e.g. ClassA in packageA.
A second class ClassB in ModelB should use ClassA as a ESuper Type.
The generated ClassA of Model A contains code that is not generated (marked @generated NOT).
I can load the Model A in Model B via the "Load Resource..." wizard. I then can use the ClassA as a Esuper Type for ClassB.
When I open the .genmodel of ModelB it offers me to generate packageA as well as packageB.
However I only want to generate packageB that contains ClassB. ClassA should be referenced from another plugin where it was already generated.

This seems like a simple problem. A class in Model B should reference a class in Model A in another package that is in another plugin.

For Example I have a generated package from Model A with the name "org.mydomain.modelA" which contains Class A.
My second package from Model B should be generated as "org.mydomain.modelB". The ClassB in this package should import the generated ClassA as "import org.mydomain.modelA.ClassA".

[Updated on: Mon, 25 February 2019 05:50] by Moderator

Re: Reference Model A classes in Model B without regenerating Model A [message #1803223 is a reply to message #1803209]

Mon, 25 February 2019 07:47

Eclipse User

Hi

It seems like B.genmodel does not specify A.genmodel as a provider of usedGenPackages.

When you Load a GenModel you get the option to re-use, so probably easiest to select B.genmodel in the Package Explorer and select Reload.... Then redirect A to A,.genmodel.

Regards

Ed Willink

Re: Reference Model A classes in Model B without regenerating Model A [message #1803224 is a reply to message #1803209]

Mon, 25 February 2019 07:48

Eclipse User

In the wizard when loading/reloading Model B you have to locate the .genmodel that was used to generate Model A so Model B's *.genmodel can reference the GenPackage for packageA as a usedGenPackage (so that it reuses the already-generated code).

Re: Reference Model A classes in Model B without regenerating Model A [message #1803227 is a reply to message #1803224]

Mon, 25 February 2019 07:58

Eclipse User

Thank you for your answers. Actually I was just missing the correct Base Package Property "org.mydomain.modelA" in my A.genmodel.
Now the reference to ClassA in ClassB is generated as intended.
What is a bit undesired is that I have to make sure not to generate ModelA again from the B.genmodel because ModelA is now included in B.genmodel.
Is there a way to mark an external package as "don't generate"?

Re: Reference Model A classes in Model B without regenerating Model A [message #1803267 is a reply to message #1803227]

Mon, 25 February 2019 20:25

Eclipse User

No. Again, in the wizard when you create or reload the *.genmodel for B you must locate the *.genmodel for A. Then you can checkmark the A's GenPackage so that it disappears from the top half of the dialog; this is how it's marked as "don't generate" or rather how it's references as "generate reusing this already generated model".

Re: Reference Model A classes in Model B without regenerating Model A [message #1803274 is a reply to message #1803267]

Tue, 26 February 2019 01:04

Eclipse User

Hi

After a mis-generation, you need to manually delete all the mis-generated files to avoid getting confused by them. If you direct the EMF generation to a distinct source folder such as emf-gen/... this is easily achieved by deleting new files in that source tree. Take care to restore successfully generated files from GIT to avoid losing @generated NOT code.

Regards

Ed Willink

Re: Reference Model A classes in Model B without regenerating Model A [message #1803289 is a reply to message #1803274]

Tue, 26 February 2019 05:58

Eclipse User

@Ed Willink
yes, manually deleting the mis-generated packages, in case I accidently generated the whole model, is what I'm resorting to now. Another important aspect is to set the All->Bundle Manifest Property of the B.genmodel to false. Otherwise it will update the exported packages to include the generated packages from Model A, which are located in another plugin.

Re: Reference Model A classes in Model B without regenerating Model A [message #1803291 is a reply to message #1803289]

Tue, 26 February 2019 06:42

Eclipse User

Hi

What you write was once true, but entries in plugin.xml now have a generated comment that echoes the "Plugin Key" Genmodel property. This usually ensures that conflicts do not arise. You can set the Plugin Key to blank to suppress specific plugin.xml contributions.

It is probably not a good idea to have more than one genmodel per plugin that specifies Generate Manifest.

Beware that you appear to be chasing down problems that are probably relics of a previous mis-generation. Once correctly configured, EMF gets most of these multi-model subtleties right. I and others have raised Bugzillas when it was wrong.

Regards

Ed Willink

Re: Reference Model A classes in Model B without regenerating Model A [message #1803298 is a reply to message #1803291]

Tue, 26 February 2019 08:13

Eclipse User

Lars, when you sayQuote:

Another important aspect is to set the All->Bundle Manifest Property of the B.genmodel to false. Otherwise it will update the exported packages to include the generated packages from Model A, which are located in another plugin.

it seems clear to me that you still have not properly configured your B.genmodel to use A.genmodel. Do that properly and you won't have any problems like what you're describing.

From the context menu of B.genmodel, invoke Reload... When you get to the last page "Package Selection" use the Add... button to load A.genmodel and then checkmark the packageA which will remove packageA from the "Root packages" viewer. Best you do this and avoid all future problems that you are likely to have....

Previous Topic:	Programmatically duplicating the effects of Generate Model Code
Next Topic:	Change behavior without modifying generated code

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 16 01:45:48 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter