| Acceleo API change and behavior change with properties [message #530492] |
Thu, 29 April 2010 18:42 |
|
This is a multi-part message in MIME format.
--------------060505090403030301020802
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 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=311045 ) and bug
311068 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=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, <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 (
http://www.eclipse.org/modeling/m2t/downloads/?project=accel eo ).
Laurent Goubet
Obeo
--------------060505090403030301020802
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="laurent_goubet.vcf"
begin:vcard
fn:Laurent Goubet
n:Goubet;Laurent
org:<a href="http://www.obeo.fr">Obeo</a>
email;internet:laurent.goubet@obeo.fr
url:http://www.obeo.fr
version:2.1
end:vcard
--------------060505090403030301020802--
|
|
|
Powered by
FUDForum. Page generated in 0.02829 seconds
] 
Search
Help
Register
Login
Home
