How to generate private/protected methods & variables using EMF?

2
votes

I wish to generate Java code using genmodel based on a UML model.

I am working on Eclipse Oxygen, UML model from Papyrus (with some usage of the Ecore profile) in order to generate the Ecore using GenModel wizard to finally generate the model Java code (standard Eclipse plugin).

I have separated my generated source from handwritten ones so a @Generated NOT + manual modification solution is to be avoided :)

Whether I change the UML visibility parameter of my attributes, nothing change in the generated model code (everything is public).

I have not found info about the possibility to do so in the doc I have read (EMF help, Vogella blog, opCoach blog, Google...)

My questions are these:

  • Is it possible to have visibility of UML objects be taken into account by GenModel processing?
  • Is this possible to setup UML Ecore profile to force visibility on generated code? (I have tried without succeed so far)
2
javaeclipseemf

2 Answers

2
votes

As far as I know it's not possible to set the access modifiers of getters/setters. I think the main issue here is that all interface methods must be public, so you can't really have any other visibility in the generated interfaces. And you usually don't want to us the implementation classes directly.

You could try to remove getters/setters from the interface. Apparently there are the suppressedGetVisibility and suppressedSetVisibility genmodel annotation to suppress getter and setter generation in the interface (suppressedIsSetVisibility and suppressedUnSetVisibility exist as well). They will only be present in the implementation class then.

Another option may be to change your metamodel and compose your model elements so that they implement two different kinds of interfaces: One public interface which describes your public API and one internal interface for internal API. Then only expose the public interfaces to the user.

Those option are certainly not the same as defining each visibility as in UML but maybe it is ok for your use case.

1
votes

Thanks to @Kapep, the solution is to look at the visibility attribute of EReference (or EAttribute if needed) stereotype applied to the corresponding Property of UML Model. Changes made there do not impact the generation of the Implementation but changes what appear in the generated interface :

  • Unspecified (default): setter & getter methods are present
  • None: setter & getter methods are not present
  • ReadOnly: only getter present

Then you are free in your man-made code that extend the generated one to use/show the way you want for getter and setter!