How to use compile-time annotations in ECore model without introducing runtime dependency [message #1717972] |
Fri, 18 December 2015 11:07 |
Andreas Sewe Messages: 111 Registered: June 2013 |
Senior Member |
|
|
Hi,
I am currently trying to figure out how to address Bug 484629. There, we have an ECore model that declares an EData Type for the @Nullable, which is then used to annotate the generated methods for a few EOperations.
Now, @Nullable is a compile-time only annotation (RetentionPolicy.CLASS), so we would rather not require the contributing bundle. Unfortunately, the generated code contains the following line, which introduces a runtime depenency on the Nullable annotation:
initEDataType(nullableEDataType, Nullable.class, "Nullable", IS_SERIALIZABLE, !IS_GENERATED_INSTANCE_CLASS);
Is there any way to avoid this? (You can find the .model and .genmodel file we use here.)
Any help is greatly appreciated.
Andreas
|
|
|
Re: How to use compile-time annotations in ECore model without introducing runtime dependency [message #1718205 is a reply to message #1717972] |
Mon, 21 December 2015 10:13 |
Carsten Reckord Messages: 27 Registered: June 2012 |
Junior Member |
|
|
I guess Ed will have a more qualified answer, but my 2 ct:
You are declaring an explicit data type for the annotation in your package. Doing it like that, the data type needs to be available at runtime for the package to be complete according to your specification.
It looks like you are only using the @Nullable annotation for one method parameter. Although I already hate myself for suggesting this, the pragmatic fix would be to either not model that method and just add it to the generated code manually, or add a "@generated NOT" to the generated javadoc and the @Nullable to the generated method by hand (the ecore code generator will recognize this and keep your custom methods intact when you regenerate).
A more complicated alternative would be to use a "text-only" annotation with some specific source URI and extending the code generation with custom dynamic templates to check for that annotation and add the proper java annotation to the generated code. To use dynamic templates, add a templates/ directory to your model project and point your genmodel to it (under "Templates & Merge", set "Dynamic Templates" to true and "Template Directory" to your template directory). Then have a look at http://git.eclipse.org/c/emf/org.eclipse.emf.git/tree/plugins/org.eclipse.emf.codegen.ecore/templates/model/Class.javajet to find the proper entry points for your custom code. Searching for ".override.javajetinc" will get you the names of the custom templates you might need.
What would be really cool is if Ecore itself would support this out-of-the-box, e.g. by utilizing the multiplicity of features, operation returns and parameters when enabled in the GenModel (that would still leave the case of multi-valued operation parameters or return values where the collection can be null, though). There is bug 362901 for @Nullable and @NonNull support in Ecore.
[Updated on: Mon, 21 December 2015 10:15] Report message to a moderator
|
|
|
Re: How to use compile-time annotations in ECore model without introducing runtime dependency [message #1718207 is a reply to message #1718205] |
Mon, 21 December 2015 10:24 |
Andreas Sewe Messages: 111 Registered: June 2013 |
Senior Member |
|
|
Hi Carsten,
thank you for your suggestions, although none of them looks particularly appealing (but that's not your fault, of course). I'll have to think about them some more and maybe discuss the opinions with Marcel, once he's back from his parental leave.
Quote:What would be really cool is if Ecore itself would support this out-of-the-box, e.g. by utilizing the multiplicity of features, operation returns and parameters when enabled in the GenModel (that would still leave the case of multi-valued operation parameters or return values where the collection can be null, though). There is bug 362901 for @Nullable and @NonNull support in Ecore.
Speaking of what would be really cool, there's also Marc-Andre Laperle's suggestion in Bug 484629 of making the code generator aware of an annotation's RetentionPolicy. If it is SOURCE or CLASS, then the code generator would refrain from generating code that introduces a runtime dependency.
Best wishes,
Andreas
|
|
|
Powered by
FUDForum. Page generated in 0.01398 seconds