Bugzilla – Full Text Bug Listing
| Summary: | Inconsistent import URI resolution | ||
|---|---|---|---|
| Product: | [Modeling] Acceleo | Reporter: | Ed Willink <ed> |
| Component: | Core | Assignee: | Project Inbox <acceleo-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ansgar.radermacher, laurent.goubet, sbouchet, stephane.begaudeau |
| Version: | 3.0.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
I have a similar problem using Acceleo 3.4.1. [the text that follows is a copy from my text on bug 349278, but is more appropriate in the context of this bug] An MTL file references a UML profile with a valid registered URI pointing to a platform:/plugin resource. However, if the plugin defining the (static) profile is present in the workspace, the EMTL resource loader somehow transforms this URI into a platform:/resource URI. This implies that the ecore associated with profile is added to the Acceleo resource set and loaded a second time. The consequence is that eClass references within the model and those passed by Acceleo are not identical Java instances although its the same thing. This in turn implies that many functions related to stereotypes do not work correctly. The problem does not appear, when the EMTL file referencing the profile is loaded by means of a plugin:/plugin reference. It also goes away, if the plugin that contains the profile definition is closed. Do you have a small example where this problem appear that you could attach on this issue? The original report contained precisely that; a small example and clarifying project open instructions as to when the problem occurs/goes away. Besides Ed's example - which is probably a better starting point - you can try out the following (sorry, a bit larger though) Install Papyrus & the following plugins from http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/extraplugins/codegen oep.acceleo oep.cpp.codegen oep.cpp.codegen.ui oep.cpp.profile oep.cpp.test You can use the sample model in oep.cpp.test and generate code for the package "Package1" (right-click on the package). If the profile is available in the 2nd workspace, code generation does not work any more for the primitive type in Package1, since the "Typedef" stereotype is not found any more (the definition is empty whereas it contained "typedef int Test" before). The code for the primitive type in included in the file generated for the package, i.e. Package1.h This has been fixed since then. |
3.1.0. The following transformation: ------------------------------ [comment encoding = UTF-8 /] [module generateGenModel('http://www.eclipse.org/emf/2002/Ecore', 'http://www.eclipse.org/emf/2002/GenModel')/] [template public generate(genModel : GenModel)] [comment @main /] [for (genPackage : GenPackage | genModel.genPackages)] [let ePackage : EPackage = genPackage.ecorePackage] [/let] [/for] [/template] ------------------------------- gives "Possible incompatible type between 'EPackage' and 'EPackage'." for the let statement, if org.eclipse.emf.codegen.ecore is open as a project in the workspace. The problem goes away if org.eclipse.emf.codegen.ecore is closed.