Community
Participate
Working Groups
When trying to re-genmodel /org.eclipse.ocl.uml/model/OCLUML.genmodel, the genmodel editor load fails with The package 'http://www.eclipse.org/uml2/4.0.0/Types#' has the same namespace URI 'http://www.eclipse.org/uml2/4.0.0/Types#' as package 'platform:/resource/org.eclipse.uml2.types/Types.ecore#' Types.genmodel, sensibly, has a development reference to ecoreDataType="Types.ecore#//Boolean". UML.ecore, erroneously, has an installed reference to 'eType="ecore:EDataType http://www.eclipse.org/uml2/4.0.0/Types#//Boolean"'. Two different reference styles make for meta-model schizopherenia as each style of reference loads a distinct resource. Changing UML.ecore to use ../../org.eclipse.uml2.types/Types.ecore# will should solve the problem, since UML.ecore and Types.ecore are both development artefacts. Alternatively if development is considered to be two phase, firstly of Types, then of UML, the reference from UML.ecore is correct, but somehow the use of Types.genmodel for the two phases must use platform: while developing Types, and http: while developing UML. This is exactly the problem my ProjectMap solves by making the two (three) names point to the one package/model, unless dual mode operation is specifically required. NB. Similar issues in Ecore.ecore have at times eliminated http: usage, though the same potential for meta-model schizophrenia exists there too. Is there a missing declaration for UML that causes genmodel to treat the two variants as one?
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.
