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 "Acceleo/Specifications/Parser Improvements"
m (→Introduction) |
m (→Backward Compatibility and Migration Paths) |
||
| Line 35: | Line 35: | ||
== Backward Compatibility and Migration Paths == | == Backward Compatibility and Migration Paths == | ||
| − | + | All the mentioned changes should not in any way affect the backward compatibility for those who have created an Acceleo generator. | |
=== Metamodel Changes === | === Metamodel Changes === | ||
| − | + | The removal of the CST would remove its metamodel and all its use in the parser and the tooling. The metamodel used by Acceleo modules (AST) would be intact. | |
=== API Changes === | === API Changes === | ||
| − | + | API removal: CST | |
| + | API change: The API provided by the Acceleo parser would evolve to reflect the removal of the CST | ||
| + | API addition: The new API using only the AST | ||
=== User Interface Changes === | === User Interface Changes === | ||
| − | + | ''none'' | |
=== Documentation Changes === | === Documentation Changes === | ||
| − | + | ''none'' | |
== Tests and Non-regression strategy == | == Tests and Non-regression strategy == | ||
Revision as of 10:28, 6 September 2011
Contents
Evolution Specification: Improvements of the Acceleo Parser
Current status is DRAFT
Preamble
This page will be used to discuss the evolution of the Acceleo parser.
The possible status are (roughly inspired by PEP-0001):
- DRAFT: Initial version and revisions based on internal feedback and discussions. DRAFT versions should never be made available outside of Obeo. They have version numbers 0.x.
- PROPOSAL: When the document is considered ready for discussion with the client, it becomes a PROPOSAL. The first such version is numbered 1.0. Feedback from the client are integrated in further versions 1.x which are still PROPOSALs. Changes from one version to the next should be documented inside the document (as the client does not have access to the source repository).
- ACCEPTED: Once agreement has been reached with the client, the document becomes ACCEPTED.This version becomes the authoritative one for guiding the evolution's actual implementation. It should normally be considered freezed. Any change to it should be exceptional and subject to approval by the project manager. Such changes must be clearly documented and justified.
- ARCHIVED: Once the evolution has been implemented _and_ its specification has been integrated into the reference documentation, this document is ARCHIVED. Any further change to the same features should be another Viewpoint Evolution .
Relevant tickets
- Bug 350219 - Introduce a cache to improve performances of the compilation and the tooling
Introduction
Several solutions are considered to improve the performances of the Acceleo Parser:
- introduction of Google Collection based caches
- removal of the CST in the parser
Detailed Specification
This section contains the "meat" of the document. Its structure will depend on the evolution itself, but it should contain:
- a clear description of the objective, i.e. why the evolution is needed.
- a justification of the approach chosen. If other approaches were considered and rejected, document it for future reference.
- limits: things that are out of the scope of the evolution.
Backward Compatibility and Migration Paths
All the mentioned changes should not in any way affect the backward compatibility for those who have created an Acceleo generator.
Metamodel Changes
The removal of the CST would remove its metamodel and all its use in the parser and the tooling. The metamodel used by Acceleo modules (AST) would be intact.
API Changes
API removal: CST API change: The API provided by the Acceleo parser would evolve to reflect the removal of the CST API addition: The new API using only the AST
User Interface Changes
none
Documentation Changes
none
Tests and Non-regression strategy
This part of the document should describe the strategy to use to correctly test the evolution and guarantee the non-regression.
Implementation choices and tradeoffs
Any important tradeoff or choice made during the implementation should be referenced here with pros/cons leading to the final decision.