Community
Participate
Working Groups
Acceleo generates an handy Java class to launch the evaluation of generation modules, wherein users can code the registration of specific ecore packages, resource factories, properties files, ... However, a third-party generation module that wants to make use of another module, yet bypasses its Java file (by directly calling one of its templates) can not easily (without copy pasting) retrieve these specific registrations. Likewise, these generated file have a lot of "noise" that clutters the file and makes changes risky (forces @generated NOT and thus prevents regeneration) and the API hardly readable. We should have a common superclass to take care of the noise, usage of "super" would allow for the API to evolve if need be, and iterating over generation modules which we need to retrieve properties of would be eased by this common class.
Created attachment 166535 [details] Patch fixing the re-using issues The attached patch introduces the new AbstractAcceleoGenerator class and changes the JET templates we use to generate our launchers to leverage that class as a superclass. This will allow us to easily have the launching API evolve while letting our clients to both take advantage of these evolutions and have custom code in their launchers. Likewise, this superclass makes it easy for third party plugins to re-use properties and package registrations done by the module they want to call.
This fix has been commited on HEAD and will be accessible in the M7 build.