Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Papyrus/Mars Work Description/NewFeature/CodeGen"
| Line 20: | Line 20: | ||
===Requirements=== | ===Requirements=== | ||
| + | |||
| + | - CGBT1: Code generation at build time should be transparent for developers and available both in their Eclipse and Maven environment | ||
| + | - CGBT2: Code generation at build time should rely on maven plugins that do not interfere with tycho’s plugins. | ||
| + | - CGBT2: Code generation at build time should generate code in a short time in order not to lengthten the Hudson build. | ||
| + | |||
| + | ===Work done=== | ||
| + | |||
| + | - Creation of the Nexus repository for Papyrus: [https://repo.eclipse.org/content/repositories/papyrus-releases/ Release] and [https://repo.eclipse.org/content/repositories/papyrus-snapshots/ Snapshot] | ||
| + | - Design of a first version of a maven EMF plugin that allows taking as input a mwe2 workflow and generating the associated EMF model, the Xtend code. | ||
| + | - Creation of a Hudson’s build to take care of such internal maven plugins [https://hudson.eclipse.org/papyrus/view/Maven/job/Papyrus-Maven-Plugins/ Hudson] | ||
| + | - Integration in all Eclipse’s plugins that manage xtend file the official xtend maven plugin | ||
Revision as of 04:49, 2 February 2015
Code generation at build time
This page presents the requirements and design notes for code generation at build time.
Contexte
Papyrus holds many technologies in charge of code generation. We can list here:
- Xtend
- Xtext and its associated Modeling Workflow Engine 2, MWE2.
In the actual Papyrus’s developing process, those technologies are called manually and at a given time. One developer is in charge to open Eclipse, and to have the Eclipse’s plugins (Xtend for instance) and to run the code generation, and then to upload code the source code repository.
At first usage, the generated code is up-to-date but it is possible that if the code generator engine has evolved, we could get some inconsistencies. For example, it could result in no up-to-date codes or missing files and sometime in files that should have been deleted/not generated.
Additionally to this problem, it introduces also bad developer’s practices. It has been noticed that developers modify directly the generated code whereas this one has to be regenerated every time. The good practices should to extend these classes in different packages. This practice was encouraged by the commit of the generated code into the source code repository, leading also to increasing the total eight of the project.
Here we propose to reintroduce different workflows in charge of code generation at build time, to remove the backup of generated codes.
Requirements
- CGBT1: Code generation at build time should be transparent for developers and available both in their Eclipse and Maven environment - CGBT2: Code generation at build time should rely on maven plugins that do not interfere with tycho’s plugins. - CGBT2: Code generation at build time should generate code in a short time in order not to lengthten the Hudson build.
Work done
- Creation of the Nexus repository for Papyrus: Release and Snapshot - Design of a first version of a maven EMF plugin that allows taking as input a mwe2 workflow and generating the associated EMF model, the Xtend code. - Creation of a Hudson’s build to take care of such internal maven plugins Hudson - Integration in all Eclipse’s plugins that manage xtend file the official xtend maven plugin
Bugzilla
The main bugzilla enhancement item tracking progress of this feature is