Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » M2T (model-to-text transformation) » Acceleo API change and behavior change with properties
Acceleo API change and behavior change with properties [message #530492] Thu, 29 April 2010 18:42
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1855
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

This mail 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
this mail 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 "" in package
"sample" of plugin "org.eclipse.acceleo.sample", you had to register the
" 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, <package name>.<file
name without extension>) ; 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 ( eo ).

Laurent Goubet

Content-Type: text/x-vcard; charset=utf-8;
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;

fn:Laurent Goubet
org:<a href="">Obeo</a>

Previous Topic:[Acceleo] Sequence Diagram to text
Next Topic:Acceleo : White space handling
Goto Forum:

Current Time: Sun Apr 22 12:25:52 GMT 2018

Powered by FUDForum. Page generated in 0.01669 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software