|
|
|
|
| Re: Acceleo : A solution for dependencies to another project with Java launcher [message #1775244 is a reply to message #1773507] |
Thu, 26 October 2017 16:57   |
 Mad Vin
Messages: 40
Registered: September 2013 |
Member |
|
|
Hi !
Thank you for your help, but i don't know what and how to do with the StandaloneProjectMap class in an Acceleo project, I've found no example on the Internet.
However, I've found something interesting to fix my problem of dependencies on the Acceleo settings.
To understand more clearly what I'm talking about, here is an easy example of Acceleo projects dependencies :
- 2 Acceleo projects : "generator.utils" and "generator.python"
- "generator.utils" is a project containing only utility queries and templates, that are useful for several kind of generators. So it contains no main template.
- "generator.python" is a project generating python language files from UML models. It depends of the "generator.util" project to be able to import and use the utility queries and templates.
- an Acceleo Configuration is created to configure a generation launcher on a main template of the "generator.python" project
=> If the Acceleo Configuration is configured to use the "Acceleo Plug-in Application" runner, the generation works.
=> If the Acceleo Configuration is configured to use the "Java Application" runner, the generation doesn't work because the dependency to the "generator.utils" project is unknown.
As said previously, the problem comes from the .emtl compiled files of Acceleo modules that reference by default the imported projects, templates and queries like this : "href="platform:/resource/generator.utils/bin/...".
But if you change the "Compilation Path Kind" setting on the "generator.python" project (Properties -> Acceleo Compiler -> Compilation Path Kind) by choosing "Absolute file system paths", the generation with the "Java Application" runner works now, because the links to the imported elements have been modified in the .emtl files like this : "href=../../../../../generator.utils/bin/..."
This solution enables to fix my problem because in my environment, the Acceleo projects must always be at a fixed position one to another. I just hope this setting exists on the old version of Acceleo I use on older projects.
However i have some questions :
1) Why this property in the Acceleo compiler settings says you use "absolute file system paths" while the generated paths are relative ones ? Paths starting by "../../../../../../" are not absolute but relative.
2) Is there a simple way (with an example) to use a property value (from a Java properties file) to replace the "platform:/resource/generator.utils" or "../../../../../../generator.utils" by the value of this property ? During the compilation ? During the execution ? Or else a "dirty" solution is to launch a script making a replaceAll in the .emtl files during the deployment of the jars on the user's PC.
Thank you.
Best regards.
|
|
|
|
|
| Re: Acceleo : A solution for dependencies to another project with Java launcher [message #1775648 is a reply to message #1775251] |
Thu, 02 November 2017 15:21 |
|
Hi,
Sorry for the delay, I had a few computer issues on my end.
What you describe here are limitations with the way Acceleo refrences its imports. As you've discovered the templates need to be references in a way we can "find" them. "platform:/" URIs are something that only exists within eclipse, and the standalone ("java application") launch will thus be unable to resolve such URIs.
You can workaround that by customizing the URIMap of the resource set used by your generator (resourceSet.getURIConverter().getURIMap().put(...)) which would allow you to tell Acceleo where the emtl files really are. You would have to register one mapping for each of the emtl files. The "registerPackages" method of the generated java launcher is a good place to configure these.
Another option would be to hook your own URIConverter in there so that you can replace the "platform:/resource/generator.utils/" URI prefix with your own relative or absolute path dependent on the user platform if you can compute it at runtime. For that, I'd suggest overriding the "createURIConverter" method of the generated java launcher, delegating to the super.createURIConverter() result if eclipse is currently running. This would be the "cleaner" option, but it'll require you to be able to actually compute (or know) the location of your other project on disk.
Laurent Goubet
Obeo
|
|
|
Powered by
FUDForum. Page generated in 0.03676 seconds
] 
Search
Help
Register
Login
Home
