Tuesday, June 1, 2010

What's new in Acceleo 3.0?

Acceleo 3.0 is on its way out. It is currently accessible in its third Release Candidate (RC3) version. The complete list of improvements and bug fixes that have been implemented in this version since the last stable release (version 0.8.1, see my previous post for explanation on this branch's version numbering) is humongous; following is the list of the most important ones. I may be succinct on the description of some of these, but you can get a full explanation of all of them in the Acceleo documentation, namely the User Guide. Be warned though, this will be a huge post :).

Compatibility and upgrading
  • Acceleo 3.0 is compatible with the three latest releases of Eclipse; Eclipse 3.4 (Ganymede), Eclipse 3.5 (Galileo) and Eclipse 3.6 (Helios). However, there are some limitations to this compatibility we maintain due to the changes that were implemented in OCL since then. For one, Acceleo modules that compile in Helios may or may not compile in Galileo and Ganymede (this will depend on the OCL features you make use of). However, Acceleo modules that compile in a given version will always compile in the subsequent Eclipse releases. Likewise, a module that has been compiled in Helios may be launched in Ganymede regardless of whether it would compile or not in that version, as our runtime shouldn't suffer from OCL breakages and improvements. All information about the compatibility will be maintained on the wiki.
  • We provide migration facilities for those of you that own Acceleo 2 templates. Specifically, we allow for the automatic migration of Acceleo 2 generation projects to Acceleo 3 projects. The automatic migration takes care of everything that could possibly be automated, leaving for you to fix no more than the Acceleo 2 features that don't have an identified mapping to Acceleo 3, or those few features that require a human hand to convert intelligently. The team is at your disposal for help if there still remains things you don't know how to convert to Acceleo 3 on the usual communication channels : the M2T newsgroup, mails, comments on this blog...
Tooling improvements
New views have been introduced to help you on several aspects of the generation cycles : module definition, launching, debugging. I'll detail each of these views one after the other.
  • First of all, the Result view allows you to get feedback on the traceability information we could retrieve during the evaluation of your modules. As long as this view has been opened, Acceleo will record every bit of information it can to synchronize your generated text with the generation module and source model. Ever wondered why such or such portion of text has been generated one way or another? What part of your generation module has generated the name of such or such method? From which element of your model has been generated such or such import? This is the view you can use to retrieve these pieces of information.
  • Next comes the Overrides view, which can be used to easily create templates or modules overriding other that are present in your instance of Eclipse. It will display every single module located either in your installed plug-ins or your workspace. All of these can be browsed down to the template level and a check box allows you to select those you wish to override. Once selected, you simply have to use the content assistant in the Acceleo Editor (CTRL+SPACE by default) and validate selected overrides for all of the overriding templates to be added to your module.
  • Last but not least, the Generation Patterns view has been introduced to help you implement behavior for an interface/class and all (or a subset of) its subtypes. For example, let's say you wish to implement a template named javaName which will generate the name of any classifier. This template will need some default behavior for interfaces and specific behavior for some classifiers. Open the Generation Patterns view, tick [template] for all selected types in its top part, and all of the types you wish to generate a template for in its bottom part. Once done, the content assist in the Acceleo editor will give you the choice [template] for all selected types which you just have to choose in order to generate all of the templates you asked for. Now that you no longer risk forgetting one or more subtypes, it is left to your discretion to implement the behavior for each of them.
  • Acceleo now provides a built-in profiler that can be used to keep track of evaluations and identify (and, hopefully, fix) bottlenecks in your generation process. The profiler is accessible through a right click on the module which execution you need to profile and the menu item Profile As => Acceleo Application.
  • The Acceleo debugger now provides you with the list of available variables at a given point in the evaluation process, along with the values of these variables for a given stack frame. Moreover, the displayed stack frames now represent Acceleo module element corresponding to your current expression stack. As for the previous release, debugging templates only requires you to set breakpoints in the Acceleo modules as you would usually with Eclipse : open an editor, double click in the left margin on the line you wish the breakpoint to be set, and launch the generation through the menu Debug As => Launch Acceleo Application.
  • Whenever possible, the warnings and errors Acceleo logs when an evaluation fails now sport the expression stack (with the lines they're at in the module files) instead of a stack trace corresponding to the Java code that was being executed at the time. This will allow for way easier debugging that ever before.

Editor Improvements
Apart from the performance improvements and minor bug fixes, the Acceleo module editor now provides refactoring actions and quick fixes.
  • First of all, you can now use the “usual” shortcut ALT+SHIFT+R to rename either modules, templates, queries, variables, ... in a coherent manner. This very same action can be accessed from right-clicking and selecting Refactor => Rename. The interface will allow you to preview the changes before validating them.
  • Portions of the module elements can be extracted as new templates through right-clicking and selecting Refactor => Extract Template (or simply using the shortcut ALT+SHIFT+T). Do note, however, that the selected text needs to be consistent. You cannot randomly select text that spans blocks of code and expect an adequate result.
  • The module editor now highlights all occurrences of the selected element when you click on it. For exemple if you place the cursor on the name of a template, all invocations of this template will be highlighted and markers will appear on the right ruler of the editor to indicate them.
  • Acceleo now provide quick fixes for some of the syntax errors detected in the editor, notably the possibility to create template or queries of a corresponding name.
  • It is recommended to use a bottom-up approach when developing generators ; Acceleo now eases this process by allowing you to initialize the content of a generation module with an example, and offering specific actions to transform these examples (static text) in dynamic OCL expressions. For example, changing all occurrences of MyClass to [c.name.toUpperFirst()/] in a single click.

Improvements and simplifications of the language
  • The MTL specification defines a standard library that offers a set of utility operations; in addition, Acceleo provides a non standard library to provide operations that greatly simplify the language and allow you to write more concise expressions, but are not part of the specification. This library has seen many additions since the 0.8 version, with things like Collections::sep(String) to insert a separator in-between every element contained by a collection, String::matches(String) to check whether a given String matches a regular expression, Collection::filter(Type) that can be used to filter out of a collection all elements that are not instances of a given type, Collection::reverse() to reverse the content of a given Collection... Take a look at the Acceleo documentation for a full reference of both standard and non standard library, along with the reference of the OCL standard library.
  • Acceleo allows you to alter the build mode, either Strict or Lax MTL compliance. Strict compliance meaning you'll get a warning for each use of a “non standard” operation.
  • Those of you that are familiar with the 2.x stream of Acceleo will be pleased to know that Acceleo 3 now provides the same post-processing facilities as its ancestor through the addition of a post directive on templates. Which allows for the modification of the text generated by a template “after generation”. For example, post(trim()) allows you to properly indent the content of the template while still leaving you the possibility to trim all unnecessary white spaces from the generated text.
  • The “+” operator can now be used whenever one of the operands is a String for concatenation, in order to avoid the verbose concat(String) OCL offers.
  • You can now use properties files to customize your generations through the addition of 4 variants of a getProperty operation in Acceleo 3. Once again, the operation reference can be looked at for the description of those services.
  • We made use of the facilities OCL provides in order to further simplify the navigation language : iterators of our [for] blocks are no longer mandatory (they'll be implicitly declared if needed and self can be used in their stead), you no longer need qualified names for your types when the metamodel is declared on the module header (or if it can be inferred from another of the declared metamodels), casting through oclAsType for all redundant expressions is no longer necessary...
  • For those expressions where OCL doesn't allow us to simplify the language, we added non standard operations. For example, sequence->select(oclIsKindOf(Type)).oclAsType(Type) is obviously redundant, but OCL doesn't allow for this expression not to define the explicit cast. In Acceleo, you can now write sequence->filter(Type) instead (see also my post on this specific issue).
  • Acceleo now allows for control characters (\n, \t, \'...) in OCL expressions.
  • Acceleo [for] blocks now declare an implicit “i” variable that can be used to retrieve the iteration count. For example, [for (Sequence{4, 5, 6})][i/], [/for] will generate 1, 2, 3.

Documentation
As advertised by Jonathan in one of his latest posts, the Acceleo documentation is complete and can be accessed from the integrated Eclipse Help through Help => Help Contents, in the Acceleo Model To Text category. We provide everything you need in order to get started with Acceleo; quick start, tutorial, user guide... and the full reference of OCL standard library and Acceleo standard and non standard libraries complete with explanations of the operations and examples.

Thursday, May 27, 2010

Acceleo : OCL made simple

It was recently asked on a mailing list how one would order the elements they iterate over in an Acceleo for loop. The elements were UML ControlFlows as in :


- Package
|-- Activity
   |-- ControlFlow1
   |-- ControlFlow2
   |-- ControlFlow3


The first answer that came to mind, using standard OCL, was :

[for (cf:ControlFlow |c.ownedElement->select(a|a.oclIsKindOf(ControlFlow))->sortedBy(e: Element | e.oclAsType(ControlFlow).name))]
...
[/for]


Pretty verbose ... If we instead make use of the implicit iterators Acceleo offers, the expression can be simplified to

[for (c.ownedElement->select(oclIsKindOf(ControlFlow))->sortedBy(oclAsType(ControlFlow).name))]
...
[/for]


But this still sports the redundancy of filtering from a list only the elements of a given type (select) and then casting the elements to ... that very same type (oclAsType). This is due to OCL not allowing Acceleo to infer the return type of the select operation. Starting from Acceleo 3.0, this expression can also be written

[for (c.ownedElement->filter(ControlFlow)->sortedBy(name))]
...
[/for]


Now that's better!

Wednesday, April 28, 2010

Acceleo API and properties files

This post is aimed at anyone that depends on or make use of the Acceleo versions built and provided within the Helios release train, namely 0.9M1-0.9M5 and 3.0M6. If you are not concerned, feel free to ignore it altogether ^^.

We added support for ".properties" files in Acceleo in the latest development version (this support appeared for 3.0M1, at the time named 0.9M1). However we realized that this first version of the properties handling left no place for customization/overriding of properties ; no place for internationalization ; and deployment of generation modules as plugins would most likely cause issues with properties lookup. Bug 311045 and bug 311068 have been opened to track these issues.

If you are one of the early adopters that made use of the property support, you'll need to cope with a little change for the M7 build : in the generated class was an "addProperties" method which allowed you to registered the full path to the properties file that was to be loaded. For example if you had a file named "messages.properties" in package "sample" of plugin "org.eclipse.acceleo.sample", you had to register the path "platform://plugin/org.eclipse.acceleo.sample/sample/messages.properties".

You will now have to return a list through the method "getProperties" (well, "addProperties" is still there yet deprecated), and this list will have to contain "sample.messages" (that is, .) ; and properties file need to be located in source folders.

Likewise, if you had set anything as "generated NOT" in the generated launcher, you will have to manually go through some minor API changes as we ended up creating a common superclass for all launchers. Specifically, launchers now "extends AbstractAcceleoLauncher", and what was once private or protected is now mostly public. This means previously generated launchers that had set any method as "generated NOT" might have to enhance the visibility from private to public. Take note that previously generated launchers that have been built and deployed will not fail and can still be used as is, though enabling re-use of your generator can only be done by letting Acceleo regenerate it (or simply code yourself to take these changes into account).

Sorry about these changes (especially past M6), but we really thought best to remove the bug-prone behavior instead of trying to maintain it since it had never been released in a stable build. The new API should allow for a real use of property files and enhance the re-usability of any generation module.

If you wish to have a look at these changes and cope with them before M7 goes live, they are all accessible in the integration build I201004291415 that went live today (see the download page for the zip or all-in-one update site downloads).

If you have any doubt or questions about these issues, feel free to answer the m2t newsgroup thread I started with a copy of this post.

Tuesday, April 13, 2010

OCL tips and tricks

Acceleo is entirely based on OCL (Object Constraint Language) for all of its model navigation syntax. Though we did simplify it as much as possible for Acceleo (getting rid of redundant casts, increasing the standard library, overriding operators, ...), there are still some things that might cause problems to any beginning user.

Here are a few of the most unsettling language particularities :
  • Operations or features conflicting with reserved OCL keywords (UML anyone?). For example, if your model has a class "Operation" with a feature named "body", then writing "myClass.body" in OCL will result in a somewhat cryptic error : "invalid token 'body'".

    The trick to access such features in OCL is to prefix the feature name with an underscore. For this example, you should have written "myClass._body".

    For the record, the full list of OCL reserved keywords as per the last available OCL version, 3.0, is as follows :

    • and
    • body
    • context
    • def
    • derive
    • else
    • endif
    • endpackage
    • if
    • implies
    • in
    • init
    • inv
    • let
    • not
    • or
    • package
    • post
    • pre
    • static
    • then
    • xor

  • Accessing enumeration values. This might sound obvious to OCL experts, but how would one compare feature values to set enumerated values? The trick here is to qualify the access. For example if you wish to check that an UML operation's visibility is "public", here is what you would do in Java : "if (operation.getVisibility() == VisibilityKind.PUBLIC".

    The OCL equivalent is "if (operation.visibility = VisibilityKind::public)".

  • There is no "elseif" in OCL ; remember to close each individual if properly with endifs : "if (...) then ... else if (...) then ... else ... endif endif"
I believe these are the most annoying (as in "the most subject to cause weird compilation errors") OCL features ; don't hesitate to add yours :p.

Wednesday, March 17, 2010

Acceleo graduation, version jumping and maintenance

Quite a few monthes ago I talked about the history of Acceleo and why its version number were regressing. Well let's talk about version jumping now :p.

Acceleo is a code generator with its own history and user community ; over the years, it grew from its first stable release to its current 2.6 version. Yet, we (the Acceleo dev team) thought that the future of code generation lied in the OMG standard "MOF Model To Text Language" (MTL) based on OCL.

An important change with this version is its switch from a self-hosted project to an eclipse foundation project. Following Eclipse rules, the project "Acceleo" was required to have an incubation phase, and this incubation called for version numbers 0.*. Started a little more than two years ago, this incubation phase is almost ready for its end.

We plan to have Acceleo graduate along with the Helios (Eclipse 3.6) release which is due to be out on June 2010. This usually means the plugin grows from version 0.9 to version 1.0. However, in order not to unsettle the existing adopter community and stay coherent with Acceleo version history, we plan to have Acceleo jump from version 0.9 (its last incubation version within Eclipse) to version 3.0 (as the last stable release of Acceleo out of Eclipse was 2.6).

At first, we planned to implement the version jump after the official release review in June 2010 ; yet to avoid unneeded unstability and after double-checking with the Eclipse management organization, we did this change before the last "pre-release candidate" milestone. With this latest build, Acceleo then jumps from '0.9.0M5' to '3.0.0M6'.

Take good note that this version jam is for those of you who plan to give (or were already giving) the new Acceleo a try. Acceleo 3.0 already sports awesome stability and a level of functionality close to if not equal to its 2.x stream to which you might be accustomed. As for this maintenance stream, we have a corrective version incoming and a 2.7 version will be out any week now.

Monday, October 26, 2009

Acceleo template editor latest improvements

We try and constantly improve the Acceleo template editor as much as we can so as to make it as intuitive as possible. I haven't posted anything here about the template editing, here is a brief recapitulation of the features we're supporting (apart from the basic functions inherited from the text editor such as search, incremental search, ...). Including the latests and in no particular order :

  • Syntax highlighting
A classic for any self-respecting code editor, Acceleo provides highlighting for all module elements, though highlighting is minimal for OCL elements.
  • Error detection
Once again, a classic for any editor which contents are compiled, interpreted, or in any way error-prone.
  • Quick fix (ctrl+shift+1)
Not much accessible in terms of quick fixes yet, Acceleo only provides the possibility to create templates or queries corresponding to "not found" compilation errors.
  • Completion (ctrl+space)
We provide code completion for templates, queries, operations and OCL standard elements.
  • Open declaration (ctrl+click ; F3)
Sorry, no fancy screenshot on this one, as I don't know how to make a meaningful one :p. Anyone familiar with Eclispe's Java editor knows this one; it basically allows you to find the declaration of any variable, type, operation, ... by a single click on its usage within the code. This allows navigation to and from other Acceleo templates, and to the metamodel when calling it on a metatype.
  • Quick outline (ctrl+o)
This allows users to quickly assess the size of a given module, find a query or template defined in it and navigate to it through a few clicks. Note that this doesn't show as much information as the regular outline view, since it is only designed to outline the module's architecture.
  • Search references (ctrl+shift+g)
Still needs some polishing to only find references in the accurate scope, yet this already allows users to find references to the selected variable or template.
  • Code folding
Granted, a screenshot is somewhat cryptic for this feature if you do not already know what code folding is. Basically, blocks of code (in Acceleo, comments, templates and queries) can be folded so that they only take two lines. If you look carefully at the screenshot below, you'll notice the "+" on the left edge right to the line numbers "4" and "8" ... as well as the fact we're missing lines 5 and 9; well, those two templates are folded :p.

More features will be included in the editor as there's a bunch of cool features that can be added to simplify template editing; next are the refactoring facilities \o/.

Thursday, October 1, 2009

Generate code with the right encoding

Up until now, Acceleo allowed you to define the encoding in which the module itself should be read in the form of a comment at the very beginning of the module :However, this only affects how Acceleo reads your template file; it will not affect how Acceleo generates files from this module. So if you want to generate an XML file, and this XML file needs be encoded in a specific encoding which is not you system's default, you're stuck :p. Or at least that was true until M2.

Let's take this basic module as an example :This simple module is entirely composed of static text; its only purpose is to generate an ant file that creates a zip from a directory in a directory named "échantillons"... yes, that's an "é". If This file is generated under windows, no problem : the default windows encoding is the same as ISO-8859-1 as far as the "é" is concerned. What if this file is generated by one of your coworker who happens to be working under linux? Here's what would be generated :
And that'd could be a tragedy if the error isn't seen before someone tries and run this ant build... and sees that you generated under something else that windows! Imagine all the chocolate needed to atone for that blasphemy! Acceleo now proposes a way to define once and for all the encoding that must be used to generate a given file, and all you need is a single parameter for the file block :Take note that this is not a behaviour described by the OMG MOFM2T specification (that sadly left all encoding issues aside). As suche this feature might change form in the future, monitor the related OMG issue if you're interested by this field.