Eclipse Community Forums - RDF feed
https://www.eclipse.org/forums/
Eclipse Community ForumsResolving oclIsTypeOf() across ecore package boundaries / Custom Ecore Metamodel Binding / Implement
https://www.eclipse.org/forums/index.php/mv/msg/12975/40767/#msg_40767
------=_NextPart_000_0016_01C80FFB.D5BEFA50
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
As part of an industry-related project I need to implement a type =
correspondence check between instances and types expressed as part of an =
ecore metamodel. They reside in different packages, and the ecore model =
is broken up into several resources. This is parallel to the =
type/instance relationship in the UML mm.
Consequently I am using the OCL console to edit my statements, Ecore =
annotations to store them within the model and a modified template =
process to embed them in the source code as Validators.
My problem is that I cannot author type compliance statements of the =
following form:
"By default, the Ecore environment uses the static EPackage registry to =
look up package names."
However...
" It can also be supplied with an alternative package registry (for =
example, one local to a ResourceSet) but it will always use the static =
registry as a backup."
The namespace-addressing problem I have described should be fairly =
common, as the necessity to address types occurs whenever a sub-type =
distinction is necessary.
Here are my questions:
1) Is there a generator-property that addresses this problem of =
resolving elements in other Ecore packages within OCL by configuration? =
If so, where is it and what is the reuired setting?
2) If the solution is not that simple, could the Eclipse Corner recipe =
be updated by the authors to address this issue?
3) Failing 1) and 2) where do I have to alter the OCL Console code and =
the Eclipse Corner recipe code to fix this myself.
Please help. I would hate to abandon OCL just because I am dealing with =
a realistically-sized metamodel and industrial requirements. This would =
be a watershed for all my critics that say that 'in a real case, you go =
back to hacking Java...'
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16544" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>As part of an =
industry-related project I need=20
to implement a type correspondence check between instances and =
types=20
expressed as part of an ecore metamodel. They reside in different =
packages,=20
and the ecore model is broken up into several resources. This is =
parallel to the=20
type/instance relationship in the UML mm.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>To follow this I am following Christian =
W. Damus's=20
recipe posted in Eclipse Corner:</FONT></DIV>
<DIV><A=20
href=3D" http://www.eclipse.org/articles/article.php?file=3DArticle-E MF-Co=
degen-with-OCL/index.html"><FONT=20
face=3DArial=20
size=3D2> http://www.eclipse.org/articles/article.php?file=3DArticle-E MF-C=
odegen-with-OCL/index.html</FONT></A></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Consequently I am using the OCL console =
to edit my=20
statements, Ecore annotations to store them within the model and a =
modified=20
template process to embed them in the source code as =
Validators.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>My <STRONG>problem</STRONG> is that I =
cannot author=20
<STRONG>type compliance statements</STRONG> of the following =
form:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>package instances</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>context =
VectorInstance</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>inv =
typeCompliance:</FONT></DIV>
<DIV><FONT face=3D"Courier New"=20
size=3D2>self.type.oclIsTypeOf(<STRONG>designtime::types::structures:: </S=
TRONG>Vector)</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>inv =
memberCompliance:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>self.members.types =3D=20
self.type->oclAsType(<STRONG>designtime::types::structures:: </STRONG>V=
ector).contentType</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT> </DIV>
<DIV><FONT face=3D"Courier New" size=3D2>endpackage</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>This <STRONG>fails because the =
namespace=20
reference for the <FONT face=3D"Courier New">types</FONT> package fails =
to=20
resolve</STRONG>.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>This is seems to be due to the fact =
that=20
(quote)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><A=20
href=3D" http://help.eclipse.org/help33/index.jsp?topic=3D/org.eclips e.ocl=
..doc/references/overview/targetMetamodels.html"><FONT=20
face=3DArial=20
size=3D2> http://help.eclipse.org/help33/index.jsp?topic=3D/org.eclips e.oc=
l.doc/references/overview/targetMetamodels.html</FONT></A> </DIV></FONT></=
DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>"<FONT face=3D"Times New Roman" =
size=3D3>By default,=20
the Ecore environment uses the static <EM class=3DCodeName>EPackage</EM> =
registry=20
to look up package names."</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>However...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>"<FONT face=3D"Times New Roman" =
size=3D3> It can also=20
be supplied with an alternative package registry (for example, one local =
to a=20
<EM class=3DCodeName>ResourceSet</EM>) but it will always use the static =
registry=20
as a backup."</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The namespace-addressing problem I have =
described=20
should be fairly common, as the necessity to address types occurs =
whenever a=20
sub-type distinction is necessary.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Here are my =
questions:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>1) Is there a generator-property that =
addresses=20
this problem of resolving elements in other Ecore packages within OCL by =
configuration? If so, where is it and what is the reuired =
setting?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>2) If the solution is not that simple, =
could the=20
Eclipse Corner recipe be updated by the authors to address this=20
issue?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>3) Failing 1) and 2) where do I have to =
alter the=20
OCL Console code and the Eclipse Corner recipe code to fix this=20
myself.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Please help. I would hate to abandon =
OCL just=20
because I am dealing with a realistically-sized metamodel and industrial =
requirements. This would be a watershed for all my critics that say that =
'in a=20
real case, you go back to hacking Java...'</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV></BODY></HTML>
------=_NextPart_000_0016_01C80FFB.D5BEFA50--]]>Jörn Guy Süß2007-10-16T03:52:47-00:00Re: Resolving oclIsTypeOf() across ecore package boundaries / Custom Ecore Metamodel Binding / Imple
https://www.eclipse.org/forums/index.php/mv/msg/12975/40924/#msg_40924
Originally posted by: cdamus.ca.ibm.com
Hi, Jörn,
I can do the following:
1. launch a run-time workbench
2. open the Interactive OCL Console
3. open an Ecore model
4. select some EClass in the Ecore model
5. input the following OCL expression:
extlibrary::BookCategory.allInstances()
6. the expected results (Mystery, Biography, ScienceFiction) are displayed
(this is with the org.eclipse.emf.examples.library plug-in installed)
So, perhaps the problem is somehow specific to your metamodel?
I see that you have a qualified path name of multiple segments. Is this
implemented as nested EPackages? Is it registered on the
org.eclipse.emf.ecore.generated_package extension point? That should make
it available in the global package registry. Do references to
designtime::types::structures::Vector resolve correctly in the OCL console
in the context of an editor on an instance of the designtime metamodel?
Concerning your question (1), there is no code-generation support for OCL in
EMF as such. However, it does generate a plugin.xml file that registers
the package on the generated_package extension point.
HTH,
Christian
Jörn Guy Süß wrote:
> As part of an industry-related project I need to implement a type
> correspondence check between instances and types expressed as part of an
> ecore metamodel. They reside in different packages, and the ecore model is
> broken up into several resources. This is parallel to the type/instance
> relationship in the UML mm.
>
> To follow this I am following Christian W. Damus's recipe posted in
> Eclipse Corner:
> http://www.eclipse.org/articles/article.php?file=Article-EMF -Codegen-with-OCL/index.html
>
> Consequently I am using the OCL console to edit my statements, Ecore
> annotations to store them within the model and a modified template process
> to embed them in the source code as Validators.
>
> My problem is that I cannot author type compliance statements of the
> following form:
>
> package instances
>
> context VectorInstance
>
> inv typeCompliance:
> self.type.oclIsTypeOf(designtime::types::structures::Vector)
>
> inv memberCompliance:
> self.members.types =
> self.type-> oclAsType(designtime::types::structures::Vector).contentType
>
> endpackage
>
> This fails because the namespace reference for the types package fails to
> resolve.
>
> This is seems to be due to the fact that (quote)
> http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse. ocl.doc/references/overview/targetMetamodels.html
>
> "By default, the Ecore environment uses the static EPackage registry to
> look up package names."
>
> However...
>
> " It can also be supplied with an alternative package registry (for
> example, one local to a ResourceSet) but it will always use the static
> registry as a backup."
>
> The namespace-addressing problem I have described should be fairly common,
> as the necessity to address types occurs whenever a sub-type distinction
> is necessary.
>
> Here are my questions:
>
> 1) Is there a generator-property that addresses this problem of resolving
> elements in other Ecore packages within OCL by configuration? If so, where
> is it and what is the reuired setting? 2) If the solution is not that
> simple, could the Eclipse Corner recipe be updated by the authors to
> address this issue? 3) Failing 1) and 2) where do I have to alter the OCL
> Console code and the Eclipse Corner recipe code to fix this myself.
>
> Please help. I would hate to abandon OCL just because I am dealing with a
> realistically-sized metamodel and industrial requirements. This would be a
> watershed for all my critics that say that 'in a real case, you go back to
> hacking Java...']]>2007-10-16T19:38:48-00:00Re: Resolving oclIsTypeOf() across ecore package boundaries / Custom Ecore Metamodel Binding / Imple
https://www.eclipse.org/forums/index.php/mv/msg/12975/40955/#msg_40955
------=_NextPart_000_0014_01C810A3.5CE19360
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_0015_01C810A3.5CE19360"
You are describing a special case. In it, there are no nested =
subpackages and no cross-references among ecore resources. Attached I =
provide you with a minimal test in the form of an EMF project. It =
consists of two ecore files, the linking genmodel and the rose model =
they were generated from. In the test, here::there::Monster lives in a =
nested package in here.ecore, and andeverywhere::CookieMonster lives in =
andeverywhere.ecore and extends Monster. Now for the test, try the OCL =
console in context CookieMonster (i.e. Ecore Editor focussed on =
CookieMonster class and set to M1) It fails with a lookup error. =20
Evaluating:
self.oclIsKindOf(here::there::Monster)
Results:
ERROR in (enumerationOrClassLiteralExpCS): (Unknown type ([here, there, =
Monster]))
This is what I need to fix inorder to build my project. This will also =
need to work in context of the generated statements based on the recipe. =
I.e. fixes have to be made to the OCL console and generator.
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message =
news:ff3408$4e6$1@build.eclipse.org...
> Hi, J=C3=B6rn,
>=20
> I can do the following:
>=20
> 1. launch a run-time workbench
> 2. open the Interactive OCL Console
> 3. open an Ecore model
> 4. select some EClass in the Ecore model
> 5. input the following OCL expression:
>=20
> extlibrary::BookCategory.allInstances()
>=20
> 6. the expected results (Mystery, Biography, ScienceFiction) are =
displayed
>=20
> (this is with the org.eclipse.emf.examples.library plug-in installed)
>=20
> So, perhaps the problem is somehow specific to your metamodel?
>=20
> I see that you have a qualified path name of multiple segments. Is =
this
> implemented as nested EPackages? Is it registered on the
> org.eclipse.emf.ecore.generated_package extension point? That should =
make
> it available in the global package registry. Do references to
> designtime::types::structures::Vector resolve correctly in the OCL =
console
> in the context of an editor on an instance of the designtime =
metamodel?
>=20
> Concerning your question (1), there is no code-generation support for =
OCL in
> EMF as such. However, it does generate a plugin.xml file that =
registers
> the package on the generated_package extension point.
>=20
> HTH,
>=20
> Christian
>=20
>=20
> J=C3=B6rn Guy S=C3=BC=C3=9F wrote:
>=20
>> As part of an industry-related project I need to implement a type
>> correspondence check between instances and types expressed as part of =
an
>> ecore metamodel. They reside in different packages, and the ecore =
model is
>> broken up into several resources. This is parallel to the =
type/instance
>> relationship in the UML mm.
>>=20
>> To follow this I am following Christian W. Damus's recipe posted in
>> Eclipse Corner:
>>
> = http://www.eclipse.org/articles/article.php?file=3DArticle-E MF-Codegen-wi=
th-OCL/index.html
>>=20
>> Consequently I am using the OCL console to edit my statements, Ecore
>> annotations to store them within the model and a modified template =
process
>> to embed them in the source code as Validators.
>>=20
>> My problem is that I cannot author type compliance statements of the
>> following form:
>>=20
>> package instances
>>=20
>> context VectorInstance
>>=20
>> inv typeCompliance:
>> self.type.oclIsTypeOf(designtime::types::structures::Vector)
>>=20
>> inv memberCompliance:
>> self.members.types =3D
>> =
self.type-> oclAsType(designtime::types::structures::Vector).contentType
>>=20
>> endpackage
>>=20
>> This fails because the namespace reference for the types package =
fails to
>> resolve.
>>=20
>> This is seems to be due to the fact that (quote)
>>
> = http://help.eclipse.org/help33/index.jsp?topic=3D/org.eclips e.ocl.doc/ref=
erences/overview/targetMetamodels.html
>>=20
>> "By default, the Ecore environment uses the static EPackage registry =
to
>> look up package names."
>>=20
>> However...
>>=20
>> " It can also be supplied with an alternative package registry (for
>> example, one local to a ResourceSet) but it will always use the =
static
>> registry as a backup."
>>=20
>> The namespace-addressing problem I have described should be fairly =
common,
>> as the necessity to address types occurs whenever a sub-type =
distinction
>> is necessary.
>>=20
>> Here are my questions:
>>=20
>> 1) Is there a generator-property that addresses this problem of =
resolving
>> elements in other Ecore packages within OCL by configuration? If so, =
where
>> is it and what is the reuired setting? 2) If the solution is not that
>> simple, could the Eclipse Corner recipe be updated by the authors to
>> address this issue? 3) Failing 1) and 2) where do I have to alter the =
OCL
>> Console code and the Eclipse Corner recipe code to fix this myself.
>>=20
>> Please help. I would hate to abandon OCL just because I am dealing =
with a
>> realistically-sized metamodel and industrial requirements. This would =
be a
>> watershed for all my critics that say that 'in a real case, you go =
back to
>> hacking Java...'
>
------=_NextPart_001_0015_01C810A3.5CE19360
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<META content=3D"MSHTML 6.00.6000.16544" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV>You are describing a special case. In it, there are no nested =
subpackages=20
and no cross-references among ecore resources. Attached I provide =
you with=20
a minimal test in the form of an EMF project. It consists of two ecore =
files,=20
the linking genmodel and the rose model they were generated from. In the =
test,=20
here::there::Monster lives in a nested package in here.ecore, and=20
andeverywhere::CookieMonster lives in andeverywhere.ecore and extends =
Monster.=20
Now for the test, try the OCL console in <STRONG>context=20
CookieMonster</STRONG> (i.e. Ecore Editor focussed on CookieMonster =
class and=20
set to M1) It fails with a lookup error. </DIV>
<DIV><B><FONT size=3D2><B><FONT size=3D2><B><FONT size=3D2>
<P align=3Dleft><FONT size=3D3>Evaluating:</FONT></P></B>
<P align=3Dleft><FONT =
size=3D3>self.oclIsKindOf(here::there::Monster)</FONT></P >
<P align=3Dleft><FONT size=3D3></FONT></P><B>
<P align=3Dleft><FONT size=3D3>Results:</FONT></P></B></FONT><FONT =
color=3D#c00000=20
size=3D3>
<P>ERROR in (enumerationOrClassLiteralExpCS): (Unknown type ([here, =
there,=20
Monster]))</P></FONT></B></FONT><FONT color=3D#c00000=20
size=3D2></FONT></B></FONT><FONT color=3D#c00000 size=3D2></FONT><FONT=20
size=3D1></DIV></FONT>
<DIV>This is what I need to fix inorder to build my project. This will =
also need=20
to work in context of the generated statements based on the recipe. I.e. =
fixes=20
have to be made to the OCL console and generator.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>"Christian W. Damus" <<A=20
href=3D"mailto:cdamus@ca.ibm.com">cdamus@ca.ibm.com</A>> wrote in =
message <A=20
href=3D"news:ff3408$4e6$1@build.eclipse.org">news:ff3408$4e6$1@build.ecli=
pse.org</A>...</DIV>>=20
Hi, J=C3=B6rn,<BR>> <BR>> I can do the following:<BR>> =
<BR>> 1.=20
launch a run-time workbench<BR>> 2. open the Interactive OCL=20
Console<BR>> 3. open an Ecore model<BR>> 4. select =
some EClass=20
in the Ecore model<BR>> 5. input the following OCL =
expression:<BR>>=20
<BR>> =
extlibrary::BookCategory.allInstances()<BR>>=20
<BR>> 6. the expected results (Mystery, Biography, =
ScienceFiction) are=20
displayed<BR>> <BR>> (this is with the =
org.eclipse.emf.examples.library=20
plug-in installed)<BR>> <BR>> So, perhaps the problem is somehow =
specific=20
to your metamodel?<BR>> <BR>> I see that you have a qualified path =
name of=20
multiple segments. Is this<BR>> implemented as nested =
EPackages? =20
Is it registered on the<BR>> org.eclipse.emf.ecore.generated_package=20
extension point? That should make<BR>> it available in the =
global=20
package registry. Do references to<BR>>=20
designtime::types::structures::Vector resolve correctly in the OCL=20
console<BR>> in the context of an editor on an instance of the =
designtime=20
metamodel?<BR>> <BR>> Concerning your question (1), there is no=20
code-generation support for OCL in<BR>> EMF as such. However, =
it does=20
generate a plugin.xml file that registers<BR>> the package on the=20
generated_package extension point.<BR>> <BR>> HTH,<BR>> =
<BR>>=20
Christian<BR>> <BR>> <BR>> J=C3=B6rn Guy S=C3=BC=C3=9F =
wrote:<BR>> <BR>>> As=20
part of an industry-related project I need to implement a =
type<BR>>>=20
correspondence check between instances and types expressed as part of=20
an<BR>>> ecore metamodel. They reside in different packages, and =
the ecore=20
model is<BR>>> broken up into several resources. This is parallel =
to the=20
type/instance<BR>>> relationship in the UML mm.<BR>>> =
<BR>>>=20
To follow this I am following Christian W. Damus's recipe posted =
in<BR>>>=20
Eclipse Corner:<BR>>><BR>> <A=20
href=3D" http://www.eclipse.org/articles/article.php?file=3DArticle-E MF-Co=
degen-with-OCL/index.html">http://www.eclipse.org/articles/article.php?fi=
le=3DArticle-EMF-Codegen-with-OCL/index.html</A><BR>>>=20
<BR>>> Consequently I am using the OCL console to edit my =
statements,=20
Ecore<BR>>> annotations to store them within the model and a =
modified=20
template process<BR>>> to embed them in the source code as=20
Validators.<BR>>> <BR>>> My problem is that I cannot author =
type=20
compliance statements of the<BR>>> following form:<BR>>>=20
<BR>>> package instances<BR>>> <BR>>> context=20
VectorInstance<BR>>> <BR>>> inv typeCompliance:<BR>>>=20
self.type.oclIsTypeOf(designtime::types::structures::Vector) <BR>>> =
<BR>>> inv memberCompliance:<BR>>> self.members.types =
=3D<BR>>>=20
self.type->oclAsType(designtime::types::structures::V ector).contentTyp=
e<BR>>>=20
<BR>>> endpackage<BR>>> <BR>>> This fails because the=20
namespace reference for the types package fails to<BR>>>=20
resolve.<BR>>> <BR>>> This is seems to be due to the fact =
that=20
(quote)<BR>>><BR>> <A=20
href=3D" http://help.eclipse.org/help33/index.jsp?topic=3D/org.eclips e.ocl=
..doc/references/overview/targetMetamodels.html">http://help.eclipse.org/h=
elp33/index.jsp?topic=3D/org.eclipse.ocl.doc/references/over view/targetMe=
tamodels.html</A><BR>>>=20
<BR>>> "By default, the Ecore environment uses the static EPackage =
registry to<BR>>> look up package names."<BR>>> <BR>>> =
However...<BR>>> <BR>>> " It can also be supplied with an=20
alternative package registry (for<BR>>> example, one local to a=20
ResourceSet) but it will always use the static<BR>>> registry as a =
backup."<BR>>> <BR>>> The namespace-addressing problem I =
have=20
described should be fairly common,<BR>>> as the necessity to =
address types=20
occurs whenever a sub-type distinction<BR>>> is =
necessary.<BR>>>=20
<BR>>> Here are my questions:<BR>>> <BR>>> 1) Is there =
a=20
generator-property that addresses this problem of resolving<BR>>> =
elements=20
in other Ecore packages within OCL by configuration? If so, =
where<BR>>> is=20
it and what is the reuired setting? 2) If the solution is not =
that<BR>>>=20
simple, could the Eclipse Corner recipe be updated by the authors =
to<BR>>>=20
address this issue? 3) Failing 1) and 2) where do I have to alter the=20
OCL<BR>>> Console code and the Eclipse Corner recipe code to fix =
this=20
myself.<BR>>> <BR>>> Please help. I would hate to abandon =
OCL just=20
because I am dealing with a<BR>>> realistically-sized metamodel =
and=20
industrial requirements. This would be a<BR>>> watershed for all =
my=20
critics that say that 'in a real case, you go back to<BR>>> =
hacking=20
Java...'<BR>></BODY></HTML>
------=_NextPart_001_0015_01C810A3.5CE19360--
------=_NextPart_000_0014_01C810A3.5CE19360
Content-Type: application/x-zip-compressed;
name="OCL does not resolve across packages.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="OCL does not resolve across packages.zip"
------=_NextPart_000_0014_01C810A3.5CE19360--]]>Jörn Guy Süß2007-10-16T23:51:56-00:00Re: Resolving oclIsTypeOf() across ecore package boundaries / Custom Ecore Metamodel Binding / Imple
https://www.eclipse.org/forums/index.php/mv/msg/12975/40987/#msg_40987
Is this (qualified path name of multiple segments) implemented as nested
EPackages?
Yes, it is modelled as nested EPackages
Is it (the set of packages) registered on the
org.eclipse.emf.ecore.generated_package extension point?
Yes, each package is registered.
Do references to designtime::types::structures::Vector resolve correctly in
the OCL console
in the context of an editor on an instance of the designtime metamodel?
No, they do not resolve. They produce the type resolution error
described in the other post. However, navigation to these features works. It
is only type navigation statements that fail.
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:ff3408$4e6$1@build.eclipse.org...
> Hi, J]]>Jörn Guy Süß2007-10-17T01:05:18-00:00Re: Resolving oclIsTypeOf() across ecore package boundaries / Custom Ecore Metamodel Binding / Imple
https://www.eclipse.org/forums/index.php/mv/msg/12975/41049/#msg_41049
Originally posted by: cdamus.ca.ibm.com
Hi, Jörn,
Thanks for the attachment. With that, I was able to generate the code and
make the following conclusions:
- EMF does not generate EPackages that have no EClassifiers, as is the
case with the "here" package. Thus, it is not present in the EPackage
registry for the OCL parser to find when looking up "here::there". See https://bugs.eclipse.org/bugs/show_bug.cgi?id=142856 for details
- if the OCL parser (the Ecore environment implementation) cannot find
the package in the registry, it tries again looking for packages by
nsPrefix for precisely this problem of classifierless parent packages.
When I tried your attached example, this actually caused the parser to
find "here::there" and successfully parse a reference to
"here::there::Monster". The parser will look for the nsPrefix that
EMF supplies by default (which you may change), which in this case
is "here.there".
Actually, one other step helped me to successfully parse: causing the
"here::there" and "andanywhere" EPackages to load by creating/loading
instance models.
The OCL parser can only find EPackages in the registry that have already
been initialized. It doesn't resolve EPackage.Descriptors because this
will load unwanted plug-ins having EPackages that don't match, and because
it assumes that if the package isn't already resolved we won't have an
instance model on which to parse OCL expressions, anyway.
In your application, this assumption isn't good. You can work around it by:
- forcibly initializing the EPackages required before doing any OCL, for
example by accessing the DesigntimePackage.eINSTANCE field
- since you probably have custom (short) nsPrefixes for your packages,
you can do what OCL does, itself, for the root "ocl" EPackage that has
no classifiers: have one or all of the subpackages create and register
it so that it is as though bugzilla 142856 were implemented
Note that it would be difficult for the OCL parser to find the right
EPackage.Descriptor in the registry in order to load the EPackage that it
is looking for. The descriptor only knows (by its key in the map) the
namespace URI, which doesn't, in general, bear any resemblance to the
EPackage name. Perhaps if EMF were to enhance the generated_package
extension point to include the qualified package name in addition to the
Java interface name, the descriptor could then have this information. Of
course, that wouldn't help with extant packages until they are regenerated
....
HTH,
Christian
Jörn Guy Süß wrote:
> You are describing a special case. In it, there are no nested subpackages
> and no cross-references among ecore resources. Attached I provide you with
> a minimal test in the form of an EMF project. It consists of two ecore
> files, the linking genmodel and the rose model they were generated from.
> In the test, here::there::Monster lives in a nested package in here.ecore,
> and andeverywhere::CookieMonster lives in andeverywhere.ecore and extends
> Monster. Now for the test, try the OCL console in context CookieMonster
> (i.e. Ecore Editor focussed on CookieMonster class and set to M1) It fails
> with a lookup error. Evaluating:
>
> self.oclIsKindOf(here::there::Monster)
>
>
> Results:
>
> ERROR in (enumerationOrClassLiteralExpCS): (Unknown type ([here, there,
> Monster]))
>
> This is what I need to fix inorder to build my project. This will also
> need to work in context of the generated statements based on the recipe.
> I.e. fixes have to be made to the OCL console and generator.
-----8<-----]]>2007-10-17T14:30:21-00:00Re: Resolving oclIsTypeOf() across ecore package boundaries / Custom Ecore Metamodel Binding / Imple
https://www.eclipse.org/forums/index.php/mv/msg/12975/41173/#msg_41173
1) Created a dynamic instance of Monster and Cookie Monster. Saved these
instance files in the workspace
2) Focussed Ecore Editor on CookieMonster class and set to M1. Repeated
Scenario
Same failure.
Is it necessary for me to generate the source of the model or does the OCL
console also work in reflective mode, i.e. in absence of generated code? For
all other statements, this seems to hold...
I have generated the model code, makes no difference...
Could you post a compiled version of the OCL console somewhere, so I can
start from an asserted and unaltered state?
Thanks for looking into it, JG
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:ff569v$sh3$1@build.eclipse.org...
> Hi, J]]>Jörn Guy Süß2007-10-18T03:24:16-00:00Re: Resolving oclIsTypeOf() across ecore package boundaries / Custom Ecore Metamodel Binding / Imple
https://www.eclipse.org/forums/index.php/mv/msg/12975/41204/#msg_41204
it easy for me to see the issue.
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:ff569v$sh3$1@build.eclipse.org...
> Hi, J]]>Jörn Guy Süß2007-10-18T03:37:53-00:00Re: Resolving oclIsTypeOf() across ecore package boundaries / Custom Ecore Metamodel Binding / Imple
https://www.eclipse.org/forums/index.php/mv/msg/12975/41327/#msg_41327
Originally posted by: cdamus.ca.ibm.com
> Still unable to get a positive parse using the OCL console. Steps tried:
>
> 1) Created a dynamic instance of Monster and Cookie Monster. Saved these
> instance files in the workspace
> 2) Focussed Ecore Editor on CookieMonster class and set to M1. Repeated
> Scenario
>
> Same failure.
>
> Is it necessary for me to generate the source of the model or does the OCL
> console also work in reflective mode, i.e. in absence of generated code?
> For all other statements, this seems to hold...
> I have generated the model code, makes no difference...
No, this is not necessary. Find attached a JUnit plug-in test project that
demonstrates how to use dynamic EMF with the OCL parser/interpreter. This
test loads the monster models into a resource set's local package registry,
creates dynamic instances of them, and parses qualified references to the
Monster and CookieMonster types in the context of some other metamodel (in
this test, Ecore).
Run the included launch configuration to check it out.
The trick with dynamic EMF is that none of the packages will be registered
in the global EPackage registry, because that is normally only done for
generated static APIs using the extension point.
> Could you post a compiled version of the OCL console somewhere, so I can
> start from an asserted and unaltered state?
The OCL console example is available as a binary on the download page. Just
take the mdt-ocl-examples-<buildid>.zip file. Or, install the
org.eclipse.emf.ocl.examples feature from the MDT update site.