- 1 The Acceleo Wishlist
- 1.1 How to contribute ?
- 1.2 Tooling
- 1.2.1 Camel case support in the Acceleo tooling
- 1.2.2 Checkstyle for Acceleo
- 1.2.3 Declaration view
- 1.2.4 Call hierarchy
- 1.2.5 Type Hierarchy
- 1.2.6 Smarter highlighting
- 1.2.7 Ant support
- 1.2.8 Maven support
- 1.2.9 Cheat sheet
- 1.2.10 Code templates
- 1.2.11 Classpath container
- 1.2.12 Improved Acceleo wizard
- 1.2.13 Documentation generation
- 1.2.14 BIRT integration
- 1.2.15 Java Integration
- 1.2.16 Integration in the Welcome page
- 1.2.17 Orion prototype
- 1.2.18 Remote Generation
- 1.2.19 Model Coverage View
- 1.2.20 Module Formatter
- 1.3 Language
- 1.4 Parser
- 1.5 Engine
- 1.6 Other
The Acceleo Wishlist
This page will contain a list of some features that have been requested by members of the Acceleo community and that are not in the roadmap of the Acceleo dev team. Those features may be realized someday and if someone wants to contribute to Acceleo, this is definitely the right place to start. Those features are ranked by type and each of them contains a small summary of the task requested and where to find a possible starting point in the Acceleo source code to realize those features.
How to contribute ?
Camel case support in the Acceleo tooling
We should be able to type something like MAM and Ctrl+Space and have MyAcceleoModule instead for example. It should work for the completion, the quick outline, etc. If you want to comment or help code this feature, see bug 325310.
Checkstyle for Acceleo
Support for checkstyle rules for Acceleo.
The documentation should be available in a documentation view, just like in Java
The call hierarchy view and its shortcut (Ctrl+Alt+H) should be available with the same behavior as in the JDT.
The type hierarchy view, its quick view and its shortcut should be available with the same behavior as in the JDT.
The highlighting of a block should not highlight the whole block but its beginning and end. It would be useful for nested "if", "for" and "else". Should also be implemented to highlight matching parenthesis, brackets, angle brackets... in OCL expressions. If you want to comment or help code this feature, see bugzilla entry 319081.
Acceleo should have more Ant tasks to manipulate the parser and the engine.
Acceleo should have a support for maven to manipulate the parser and the engine.
Cheat sheets should be integrated to Acceleo in order to provide the user with tutorials and documentation.
A preference menu with code templates for Acceleo should be available.
The Acceleo builder/compiler and the Acceleo runtime should be available as classpath container in order to be easily included in Java project within Eclipse. An example of what the result could look like is available here. If you want to comment or help code this feature, see bug 330351.
Improved Acceleo wizard
The Acceleo wizard allow the user to create an Acceleo project and then to create a UI plugin for Eclipse containing the generators created with Acceleo in order to integrate them seamlessly within Eclipse. This wizard should provide more option for the creation of the µEclipse plugin containing the generator. On of these options could be to be able to have the bundle in the classpath thanks to a classpath container.
Just like Java can generate a HTML documentation, we would like to be able to generate a HTML version of the Acceleo documentation.
Acceleo should have a connector with BIRT to use the graph framework of BIRT for the profiling or the traceability.
Improve Java services.
Integration in the Welcome page
Acceleo should be integrated in the welcome page of Eclipse.
Acceleo should have a working prototype on Orion
Currently, Acceleo only knows how to launch a generation on emtl files that are on the local machine (file-scheme URIs). It would be interesting for it to also work with "remote" emtl that could be located on a server (http, ftp...), on a repository (CVS, SVN, git...) and so on.
Model Coverage View
The Model Coverage View should display the element from the metamodel that are used by the generator. The view should present a tree based representation of the model just like the Ecore Sample Editor with the element used by the generator in green and the unused elements in red. This view should also be linked to the drag and drop system of the Acceleo editor in order to generate a new template / query for an element. This view could also modify the completion within the Acceleo Editor by modifying the completion for a new template / query for a completion typed with the unused elements of the metamodel. The view should also let the user provide an example of a model using the current metamodel in order to limit the elements shown in the view to the element used in the example model in order to improve the example based approach.
Though most of the Acceleo modules cannot be formatted lest we prevent the generation of some whitespaces, there are places in the Acceleo modules that can be "safely" formatted. It would be interesting to isolate these "safe" locations and determine a set of rules for their formatting. For example, OCL expressions (as in Acceleo queries' bodies) can be safely altered without changing their output. That would allow us to properly format an OCL "if" or "let" expression for example.
Post-Processing at the file level
Acceleo should provide a way to create services that will modify the file as a whole after its generation. For example when generating Java, we'd like to have a service which would record a list of Strings as the evaluation runs (for example, "java.util.List", "java.util.Set", "java.util.ArrayList", ...) and which would add the "import" clauses for all of the Strings contained by this list to the generated file.
The Acceleo parser should be able to parse several files at the same time.
Compilation on the fly
The AbstractAcceleoGenerator should be changed to allow the compilation on the fly of the mtl files if the emtl files are not found.
Debugging of OCL expressions
The Acceleo debugger should be able to visit the content of an OCL expression.
Export the profiling data into "gprof" file
Acceleo should provide a way to create the data from the profiling as a "gprof" file. If you want to comment or help code this feature, see bug 293304.
Stand alone unit testing framework
Acceleo modules should be easy to test thanks to a stand alone testing framework. An example of this framework can be seen here.
|Project||Project · Installation · New & noteworthy · Release review · API policy · Retention policy · Next · Checklist|
|Features||Acceleo Features · Runtime · Acceleo editor · Views & Perspective · Debugger · Profiler · Traceability · Wishlist · Interpreter · Maven|
|User documentation||Getting Started · Acceleo operations reference · OCL operations reference · Text Production Rules · Migration From Acceleo 2.x · Best Practices · Videos · FAQ|
|Developer documentation||Source code · How to contribute · Compatibility · MOFM2T specification · OCL specification|
|Community||Blogs · Professional Support · Report a bug|