Eclipse Community Forums: EMF » genmodel code generation removes extensions in plugin.xml

Help

Home

Home » Modeling » EMF » genmodel code generation removes extensions in plugin.xml

Show: Today's Messages :: Show Polls :: Message Navigator

genmodel code generation removes extensions in plugin.xml [message #1790257]

Thu, 07 June 2018 15:29

smaoui asma

Messages: 50
Registered: July 2009
Location: Paris Saclay, France

Member

Step to reproduce :

1) create a genModel from a UML model.
2) generate the code from it
3) add some extentions to the plugin.xml
4) change the uml model, reload the resource in the genmodel and regenerate code
5) after regeneration, the plugin.xml did not contain the added extentions

...I have to re add them each time I generate code from my model.

Why the code generation did change the plugin.xml ?

Thanks

Report message to a moderator

Re: genmodel code generation removes extensions in plugin.xml [message #1790264 is a reply to message #1790257]

Thu, 07 June 2018 16:27

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

There are a couple of genmodel options that interact with MANIFEST/plugin refresh.

Template&Merge->Plugin Key
All->Bundle Manifests

Perhaps you have inappropriate choices. I find a blank plugin key helpful.

Regards

Ed Willink

Report message to a moderator

Re: genmodel code generation removes extensions in plugin.xml [message #1790271 is a reply to message #1790264]

Thu, 07 June 2018 17:16

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

The plugin.xml is generally merged so at worst I expect nothing to be changed. I certainly don't expect that the file will simply be overwritten. And as Ed W suggests, you can disable updating the plugin.xml at all.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: genmodel code generation removes extensions in plugin.xml [message #1790307 is a reply to message #1790271]

Fri, 08 June 2018 08:12

smaoui asma

Messages: 50
Registered: July 2009
Location: Paris Saclay, France

Member

Hello,

Thank you both for the quick answer !

Indeed, a blank plugin Key resolves the problem :)

@Merks : may be there is a problem in the merge. only generated extensions are kept. extensions added by hand are removed.

@both : where can I find a documentation about the meaning of all this options (and options displayed when reloading a resource from the genModel : 21 options with Process/Ignore possibilites)

it is not very trivial to try to leave a blank "Plugin Key" to disable updating the plugin.xml.

Thank you again !

Asma

Report message to a moderator

Re: genmodel code generation removes extensions in plugin.xml [message #1790309 is a reply to message #1790271]

Fri, 08 June 2018 08:17

Ansgar Radermacher

Messages: 461
Registered: March 2011
Location: Paris Saclay, France

Senior Member

Thanks for the information! I doubt that it is merged, as it removes everything not generated by itself (eventually a bug?). It's good to know that it can be deactivated (saves me a "replace with head revision" cycle after each generation ...)

Report message to a moderator

Re: genmodel code generation removes extensions in plugin.xml [message #1790368 is a reply to message #1790309]

Fri, 08 June 2018 16:57

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

Given I have a great many models in multiple projects with many hand-written additions that are not removed during regeneration, I'm sure there's something special about your scenario that you've not included in your description.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: genmodel code generation removes extensions in plugin.xml [message #1790373 is a reply to message #1790368]

Fri, 08 June 2018 17:28

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi Ed

I think that the problem occurs for multiple models in a single project. Generating any one model refreshes the plugin.xml, correctly for those @generated, but badly for manual additions; each single model generation corrupts the others. This contrasts with other genmodel generation that is not shared and has a sophisticated merge capability.

I set the plugin key blank and consequently the above problems vanish. I usually only generate once with a non-None Resource Type to get the XXXResourceImpl structure and then set to None Resource Type thereafter.

(It might be more sensible to have a blank bundle id as the merge/not-merge control.)

Regards

Ed Willink

Report message to a moderator

Re: genmodel code generation removes extensions in plugin.xml [message #1790380 is a reply to message #1790373]

Fri, 08 June 2018 21:47

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

Multiple models in a single project doesn't generally sound sound to begin with... Furthermore, I don't see how this would affect manual additions to the plugin.xml: as with the @generated Javadoc annotation in the Java code, generally declarations in the plugin.xml must "invite" being merged (and correspondingly removal) with an XML annotation. In any case, if someone has a reproducible scenario to illustrate what to me is just a hypothetical problem, I could look at that, but I must say up front that two *.genmodels in the same project using the same merge key will necessarily invite removal/replacement, so that will not be a problem that can or will be fixed.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: genmodel code generation removes extensions in plugin.xml [message #1790388 is a reply to message #1790380]

Sat, 09 June 2018 05:16

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

One use case for multiple models per plugin is a test plugin, potentially one model per test. The OCL Xtext tests plugin has 5 genmodels statically defined in GIT, and many more dynamically created during testing.

But I agree that the effort to support merging into something that is only partially under EMF's control is not worthwhile. Blank plugin-keys are adequate.

(On the other hand Xtext demonstrates a need for a disciplined MANIFEST/plugin merge capability without which Xtext just produces ..._gen files awaiting a manual merge.)

Regards

Ed Willink

Report message to a moderator

Re: genmodel code generation removes extensions in plugin.xml [message #1790391 is a reply to message #1790388]

Sat, 09 June 2018 07:40

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

Ed, are you implying that org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.mergePluginXML(String, String, String) and org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.mergeManifest(String, String) do "undisciplined" merging? Is that in contrast to Ansgar's implication that this logic simply overwrites the file?

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: genmodel code generation removes extensions in plugin.xml [message #1790394 is a reply to message #1790391]

Sat, 09 June 2018 08:11

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

Apologies, perhaps my terminology is wrong. My recollection is that I was having trouble with plugin.xml being corrupted and you pointed me at blank Plugin Key since when my plugin.xml behaviour is satisfactory. When I tried to look at the code I could not see any countetpart for plugin.xml of the begin/end that the Java merger has.

Regards

Ed Willink

Report message to a moderator

Re: genmodel code generation removes extensions in plugin.xml [message #1790399 is a reply to message #1790394]

Sat, 09 June 2018 09:13

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

The key drives the generation of markers (XML comments) in the plugin.xml, e.g.,

   <extension point="org.eclipse.emf.ecore.generated_package">
      <!-- @generated setup -->
      <package
            uri="http://www.eclipse.org/oomph/setup/1.0"
            class="org.eclipse.oomph.setup.SetupPackage"
            genModel="model/Setup.genmodel"/>
   </extension>

Those are used to identify things that should be merged, and things not so marked should remain untouched. I doubt such things don't work properly because we've used this heavily in Oomph's EMF models...

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Previous Topic:	Resource.getDefaultSaveOptions()
Next Topic:	[EMF compare] ExampleLauncher problem

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 23 15:24:26 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter