Bugzilla – Full Text Bug Listing
| Summary: | Types package meta-model schizophrenia while genmodeling OCLUML.genmodel. | ||
|---|---|---|---|
| Product: | [Modeling] MDT.UML2 | Reporter: | Ed Willink <ed> |
| Component: | Core | Assignee: | UML2 Inbox <mdt-uml2-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | Kenn.Hussey |
| Version: | 3.2.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
|
Description
Ed Willink
Were you using a recent (i.e., November 28 or later) build while doing this? The UML2 code generator has changes that treat the Types package as "built in" when constructing generator models... My development workspace uses 20111128 for many plugins but codegen is 20111202 and I debugged in a run-time Eclipse using GIT master. The bug 366803 fix seems to solve a lot of obscure issues and has yet to appear in a build, so I'll comment again once I have a clean M4 as reference. No. This is still present on a clean M4. Just try to open /org.eclipse.ocl.uml/model/OCLUML.genmodel with the GenModel editor. (In reply to comment #3) > No. This is still present on a clean M4. Just try to open > /org.eclipse.ocl.uml/model/OCLUML.genmodel with the GenModel editor. When was that generator model created? I tried reloading it (ignoring the error that comes up), saving it, and re-opening it and everything seemed to be fine thereafter... (In reply to comment #4) > When was that generator model created? It was updated in September to provide the missing Types.genmodel. > I tried reloading it (ignoring the error that comes up), But it's a real error. > saving it, and re-opening it and everything seemed to be fine > thereafter... Only because the reload stripped the explicit usedGenPackage reference to Types.genmodel. The normal policy is to reference all genmodels explicitly. It seems there is now an implicit reference and it is the explicit/implicit that is causing the conflict. (In reply to comment #5) > > I tried reloading it (ignoring the error that comes up), > > But it's a real error. I'm not sure I agree (see below). > > saving it, and re-opening it and everything seemed to be fine > > thereafter... > > Only because the reload stripped the explicit usedGenPackage reference to > Types.genmodel. Right, because references to the Types model are implicit (as are references to Ecore, XML Types, and XML Namespace from EMF). > The normal policy is to reference all genmodels explicitly. It seems there is > now an implicit reference and it is the explicit/implicit that is causing the > conflict. Right, but this is not a "normal" case; handling of types from the Types model had to be handled in a special way just like types from the Ecore, XML Types, and XML Namespace model had to be (in EMF) in order to bootstrap UML2. I spent a non-trivial amount of time getting this to work and I don't know any other way around it... I can well understand that distinguishing a Types package from the Types package can be difficult; OCL has the same and more problems. Your solution may well be the correct one; all you need to do is recognize that the implicit Types.genmodel has been specified explicitly as well and silently ignore the 'redundant' specification. In order for downstream tooling to be able to examine genmodels and see the closure of all additional gen declarations, it would seem desirable for the implicit genmodel, to be automatically inserted, rather than automatically removed. So, I suggest that my genmodel with an explicit Types genmodel is the correct case. One with an implicit Types genmodel is incomplete and requires all consumers to use an appropriate helper algorithm to find it. I'm not sure it is actually correct for your genmodel to reference the Types genmodel explicitly; is it even used? Looking at OCLUML.uml, I can't see how/where... True. It's not used, but it could be. If the OCL UML binding was not now a legacy approach, I suppose it should be reworked to exploit the Primitive Types package. [Instead I have the problem of how and whether to separate the Types package once a QVTo transformation direct from UML.xmi is used to prepare the subset OCL metamodel.] Hmm. I'm inclined to consider this issue a red herring. I've tried creating model from scratch and importing it into a generator model and got the expected result. I really think the problem with your genmodel stems from having created it using an intermediate UML2 build (i.e., in which the built-in handling of the Types model was not yet in place)... Ok. Let's wait for a concrete rather than philosophical use case problem. Agreed. Resolving as "WONTFIX" for now. Please re-open this bug or open a new one in the event that you identify a concrete use case for the issue. |