| Summary: | URI serialization with binary resources | ||
|---|---|---|---|
| Product: | [Modeling] Acceleo | Reporter: | Laurent Goubet <laurent.goubet> |
| Component: | Core | Assignee: | Project Inbox <acceleo-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | mariot.chauvin |
| Version: | 3.0.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
This only happens with binary serialization of the compiled emtl file, and only if the target metamodel is in the workspace when developing the generation module. Since there is no means for us to influence the uri handlers during binary serialization, we do not plan on trying to fix this last case. |
A module looking as the following : ----- [module myModule('http://myMetamodel')/] [template public mytemplate(myArg : TypeFromMyMetamodel)] ... ----- ends up when reloaded with a proxy URI of the form /myMetamodelProject/myMetamodel.ecore#//TypeFromMyMetamodel i.e : we've lost the "logical" http-protocol URI of the metamodel in favor of the "project-relative" URI... which cannot be resolved most of the time. Switching back to XMI serialization of the EMTL will properly use the http protocol for our proxy, making it resolveable.