Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » OCL Question
| OCL Question [message #449] |
Sat, 10 September 2005 03:06  |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Hi,
this thread started in GMF newsgroup and as Ed suggested, I copied it to this new newsgroup.
To sum it up, I'd like to use my own EPackage.Registry with the EcoreEnvironment.
Details of the problem are described below...
Cheers
/Eike
Vishy, Ed,
Thanks for your answers!
I should have been asking a bit more detailed, because I'm pretty sure
about EMF concepts including resource framework (I developed the CDOResourceImpl).
Regarding EMF-OCL I even digged into the implementation of
static public EPackage org.eclipse.emf.ocl.parser.EcoreEnvironment.findPackage(List packageNames)
There we can find a hard-coded
Map registry = EPackage.Registry.INSTANCE;
for (Iterator iter = registry.values().iterator(); iter.hasNext();) {
...
which even can not be overridden since the method is static ;-(
I have the feeling that some architecture work is still missing to achieve
a degree of customizability similar to that of EMF.
I should have been asking for when this might happen.
Cheers
/Eike
p.s. I'll copy this thread to EMFT newsgroup, too...
vramaswa@ca.ibm.com schrieb:
>
> Hi Eike,
> The resource set has its own local registry. The following is the
> javadoc on the resource set API.
> /**
> * Returns the registry used for looking up a package based namespace.
> * <p>
> * An implementation will typically provide a registry that delegates to
> * the {@link org.eclipse.emf.ecore.EPackage.Registry#INSTANCE global}
> package registry.
> * As a result, registrations made in this registry are <em>local</em>
> to this resource set,
> * i.e., they augment or override those of the global registry.
> * </p>
> * @return the registry used for looking up a package based namespace.
> */
> EPackage.Registry getPackageRegistry();
>
>
> Thanks
> Vishy
Hi,
Is there a possibility to use an EPackage.Registry other than the global one?
Cheers
/Eike
|
|
| |
| Re: OCL Question [message #472 is a reply to message #458] |
Mon, 12 September 2005 13:59  |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
hi christian,
as i understand the new code, it allows to specify a single package
for the EcoreEnvironment. is this considered to be a "starting"
package? what about the other packages of my registry, are they found
by following associations to referenced EClasses?
am i expected to provide a new EcoreEnvironment for each validation
in my model?
i'm also not sure about your comment on resource sets. ok, a resource set
has associated a local EPackage.Registry, but i think in the context of
an OCL environment only the package registry itself is of importance,
not the containing resource set. what do you think?
i'd like to open a bugzilla, but at the moment i could only explain
my problem. i need my package registry being used by the OCL parser/evaluator.
which is the "plus" of flexibility that you have in mind?
cheers
/eike
cdamus@ca.ibm.com schrieb:
> (likewise copied from the GMF newsgroup)
>
> Hi, Eike,
>
> I recently committed a refactoring of the OCL parser's environment
> infrastructure that allows clients to provide their own Environment
> implementations that look up package names and other names.
>
> Have a look at the org.eclipse.emf.ocl.parser.EnvironmentFactory and the
> org.eclipse.emf.ocl.helper.IOclHelper interfaces for details.
>
> Of course, creating your own environment implementation isn't the greatest
>
> because everybody would want resource-set-specific package lookup, not
> just you. That should be supported by the default Ecore environment
> implementation. The only trouble is, that currently the OCL parser knows
> nothing about resource sets, so the creation of environments would need to
>
> be (optionally) parameterized by a resource set. This would be worth
> raising an enhancement for in Bugzilla (hint, hint).
>
> Christian
>
|
|
|
| Re: OCL Question [message #484 is a reply to message #472] |
Mon, 12 September 2005 15:00 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Eike,
I was sloppy in my response: the only interesting parameter to the
environment would be the package registry, as you say, regardless of
whether it came from a resource set or otherwise.
If you extend the org.eclipse.emf.ocl.parser.EcoreEnvironment class, you
can override the "EPackage lookupPackage(List path)" method to fall back
to a registry of your choosing. The "default package" is, in a sense, a
"starting package". It represents the OCL's optional context package,
which is the package in which unqualified classifier names are expected to
be found and in which unqualified or partially qualified package names can
be found. The parser's implementation extends that a bit by trying to
find names in the super-package chain if they cannot be found in the
default package. The final fall-back is to look for an absolute package
path in the global registry. This is where you can can customize the
registry to use, in your subclass.
You should not need to create a new environment for each OCL expression
that you parse, especially if you always use the same resource set and its
same registry. You could create a custom EnvironmentFactory to create
your custom Environments, and use that with an IOclHelper, to let it
create the environments when needed. That would probably be more than you
really need, though. The EnvironmentFactory is more useful for
applications that need to dynamically map their metamodels to Ecore (such
as one might do for SQL or UML) where the environment is really accessing
a non-ecore metamodel.
Regarding the bugzilla, I think the statement in your last post is all
that is needed to make the problem plain. We just need to provide a basic
environment implementation that allows a client to plug in an optional
package registry (the default being the shared registry). No more pluses
than that. :-)
HTH,
Christian
|
|
|
| Re: OCL Question [message #498 is a reply to message #484] |
Tue, 13 September 2005 01:45 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
hi christian,
i just tried to file the bugzilla as you proposed, but the EMFT
product is configured for Website component bugs only at the moment...
cheers
/eike
cdamus@ca.ibm.com schrieb:
> Hi, Eike,
>
> I was sloppy in my response: the only interesting parameter to the
> environment would be the package registry, as you say, regardless of
> whether it came from a resource set or otherwise.
>
> If you extend the org.eclipse.emf.ocl.parser.EcoreEnvironment class, you
> can override the "EPackage lookupPackage(List path)" method to fall back
> to a registry of your choosing. The "default package" is, in a sense, a
> "starting package". It represents the OCL's optional context package,
> which is the package in which unqualified classifier names are expected to
> be found and in which unqualified or partially qualified package names can
> be found. The parser's implementation extends that a bit by trying to
> find names in the super-package chain if they cannot be found in the
> default package. The final fall-back is to look for an absolute package
> path in the global registry. This is where you can can customize the
> registry to use, in your subclass.
>
> You should not need to create a new environment for each OCL expression
> that you parse, especially if you always use the same resource set and its
> same registry. You could create a custom EnvironmentFactory to create
> your custom Environments, and use that with an IOclHelper, to let it
> create the environments when needed. That would probably be more than you
> really need, though. The EnvironmentFactory is more useful for
> applications that need to dynamically map their metamodels to Ecore (such
> as one might do for SQL or UML) where the environment is really accessing
> a non-ecore metamodel.
>
> Regarding the bugzilla, I think the statement in your last post is all
> that is needed to make the problem plain. We just need to provide a basic
> environment implementation that allows a client to plug in an optional
> package registry (the default being the shared registry). No more pluses
> than that. :-)
>
> HTH,
>
> Christian
|
|
|
| Re: OCL Question [message #510 is a reply to message #498] |
Tue, 13 September 2005 07:21 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Eike,
Yes, we have no appropriate bugzilla components yet. Even the CVS
infrastructure for these components isn't set up quite right yet. :-(
I'll work at getting this improved as soon as possible.
Eike Stepper wrote:
> hi christian,
>
> i just tried to file the bugzilla as you proposed, but the EMFT
> product is configured for Website component bugs only at the moment...
>
> cheers
> /eike
>
>
>
>
> cdamus@ca.ibm.com schrieb:
>
>> Hi, Eike,
>>
>> I was sloppy in my response: the only interesting parameter to the
>> environment would be the package registry, as you say, regardless of
>> whether it came from a resource set or otherwise.
>>
>> If you extend the org.eclipse.emf.ocl.parser.EcoreEnvironment class,
>> you can override the "EPackage lookupPackage(List path)" method to
>> fall back to a registry of your choosing. The "default package" is,
>> in a sense, a "starting package". It represents the OCL's optional
>> context package, which is the package in which unqualified classifier
>> names are expected to be found and in which unqualified or partially
>> qualified package names can be found. The parser's implementation
>> extends that a bit by trying to find names in the super-package chain
>> if they cannot be found in the default package. The final fall-back
>> is to look for an absolute package path in the global registry. This
>> is where you can can customize the registry to use, in your subclass.
>>
>> You should not need to create a new environment for each OCL
>> expression that you parse, especially if you always use the same
>> resource set and its same registry. You could create a custom
>> EnvironmentFactory to create your custom Environments, and use that
>> with an IOclHelper, to let it create the environments when needed.
>> That would probably be more than you really need, though. The
>> EnvironmentFactory is more useful for applications that need to
>> dynamically map their metamodels to Ecore (such as one might do for
>> SQL or UML) where the environment is really accessing a non-ecore
>> metamodel.
>>
>> Regarding the bugzilla, I think the statement in your last post is
>> all that is needed to make the problem plain. We just need to
>> provide a basic environment implementation that allows a client to
>> plug in an optional package registry (the default being the shared
>> registry). No more pluses than that. :-)
>>
>> HTH,
>>
>> Christian
>
|
|
| | |
| Re: OCL Question [message #549 is a reply to message #498] |
Tue, 13 September 2005 08:57 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Eike,
For now, we've been accepting bugzillas in the GMF project for these
EMFT-bound components. I guess we'll be transferring them all over to
EMFT when it is available.
cW
Eike Stepper wrote:
> hi christian,
>
> i just tried to file the bugzilla as you proposed, but the EMFT
> product is configured for Website component bugs only at the moment...
>
> cheers
> /eike
>
>
>
>
> cdamus@ca.ibm.com schrieb:
>
>> Hi, Eike,
>>
>> I was sloppy in my response: the only interesting parameter to the
>> environment would be the package registry, as you say, regardless of
>> whether it came from a resource set or otherwise.
>>
>> If you extend the org.eclipse.emf.ocl.parser.EcoreEnvironment class,
>> you can override the "EPackage lookupPackage(List path)" method to
>> fall back to a registry of your choosing. The "default package" is,
>> in a sense, a "starting package". It represents the OCL's optional
>> context package, which is the package in which unqualified classifier
>> names are expected to be found and in which unqualified or partially
>> qualified package names can be found. The parser's implementation
>> extends that a bit by trying to find names in the super-package chain
>> if they cannot be found in the default package. The final fall-back
>> is to look for an absolute package path in the global registry. This
>> is where you can can customize the registry to use, in your subclass.
>>
>> You should not need to create a new environment for each OCL
>> expression that you parse, especially if you always use the same
>> resource set and its same registry. You could create a custom
>> EnvironmentFactory to create your custom Environments, and use that
>> with an IOclHelper, to let it create the environments when needed.
>> That would probably be more than you really need, though. The
>> EnvironmentFactory is more useful for applications that need to
>> dynamically map their metamodels to Ecore (such as one might do for
>> SQL or UML) where the environment is really accessing a non-ecore
>> metamodel.
>>
>> Regarding the bugzilla, I think the statement in your last post is all
>> that is needed to make the problem plain. We just need to provide a
>> basic environment implementation that allows a client to plug in an
>> optional package registry (the default being the shared registry). No
>> more pluses than that. :-)
>>
>> HTH,
>>
>> Christian
|
|
|
| Re: OCL Question [message #562 is a reply to message #549] |
Tue, 13 September 2005 11:31 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------020101030304010200030602
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Christian/Eike,
We now have the bugzilla components set up in EMFT so we can handle the
bugzillas now:
Christian W. Damus wrote:
>
> Hi, Eike,
>
> For now, we've been accepting bugzillas in the GMF project for these
> EMFT-bound components. I guess we'll be transferring them all over to
> EMFT when it is available.
>
> cW
>
> Eike Stepper wrote:
>
>> hi christian,
>>
>> i just tried to file the bugzilla as you proposed, but the EMFT
>> product is configured for Website component bugs only at the moment...
>>
>> cheers
>> /eike
>>
>>
>>
>>
>> cdamus@ca.ibm.com schrieb:
>>
>>> Hi, Eike,
>>>
>>> I was sloppy in my response: the only interesting parameter to the
>>> environment would be the package registry, as you say, regardless of
>>> whether it came from a resource set or otherwise.
>>>
>>> If you extend the org.eclipse.emf.ocl.parser.EcoreEnvironment class,
>>> you can override the "EPackage lookupPackage(List path)" method to
>>> fall back to a registry of your choosing. The "default package" is,
>>> in a sense, a "starting package". It represents the OCL's optional
>>> context package, which is the package in which unqualified
>>> classifier names are expected to be found and in which unqualified
>>> or partially qualified package names can be found. The parser's
>>> implementation extends that a bit by trying to find names in the
>>> super-package chain if they cannot be found in the default package.
>>> The final fall-back is to look for an absolute package path in the
>>> global registry. This is where you can can customize the registry
>>> to use, in your subclass.
>>>
>>> You should not need to create a new environment for each OCL
>>> expression that you parse, especially if you always use the same
>>> resource set and its same registry. You could create a custom
>>> EnvironmentFactory to create your custom Environments, and use that
>>> with an IOclHelper, to let it create the environments when needed.
>>> That would probably be more than you really need, though. The
>>> EnvironmentFactory is more useful for applications that need to
>>> dynamically map their metamodels to Ecore (such as one might do for
>>> SQL or UML) where the environment is really accessing a non-ecore
>>> metamodel.
>>>
>>> Regarding the bugzilla, I think the statement in your last post is
>>> all that is needed to make the problem plain. We just need to
>>> provide a basic environment implementation that allows a client to
>>> plug in an optional package registry (the default being the shared
>>> registry). No more pluses than that. :-)
>>>
>>> HTH,
>>>
>>> Christian
>>
--------------020101030304010200030602
Content-Type: multipart/related;
boundary="------------010005050701070502000908"
--------------010005050701070502000908
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Christian/Eike,<br>
<br>
We now have the bugzilla components set up in EMFT so we can handle the
bugzillas now:<br>
<blockquote><img src="cid:part1.05030107.09010702@ca.ibm.com" alt=""><br>
</blockquote>
Christian W. Damus wrote:
<blockquote cite="middg6i9s$dl8$1@news.eclipse.org" type="cite"><br>
Hi, Eike,
<br>
<br>
For now, we've been accepting bugzillas in the GMF project for these
EMFT-bound components. I guess we'll be transferring them all over to
EMFT when it is available.
<br>
<br>
cW
<br>
<br>
Eike Stepper wrote:
<br>
<blockquote type="cite">hi christian,
<br>
<br>
i just tried to file the bugzilla as you proposed, but the EMFT
<br>
product is configured for Website component bugs only at the moment...
<br>
<br>
cheers
<br>
/eike
<br>
<br>
<br>
<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:cdamus@ca.ibm.com">cdamus@ca.ibm.com</a> schrieb:
<br>
<br>
<blockquote type="cite">Hi, Eike,
<br>
<br>
I was sloppy in my response: the only interesting parameter to the
environment would be the package registry, as you say, regardless of
whether it came from a resource set or otherwise.
<br>
<br>
If you extend the org.eclipse.emf.ocl.parser.EcoreEnvironment class,
you can override the "EPackage lookupPackage(List path)" method to fall
back to a registry of your choosing. The "default package" is, in a
sense, a "starting package". It represents the OCL's optional context
package, which is the package in which unqualified classifier names are
expected to be found and in which unqualified or partially qualified
package names can be found. The parser's implementation extends that a
bit by trying to find names in the super-package chain if they cannot
be found in the default package. The final fall-back is to look for an
absolute package path in the global registry. This is where you can
can customize the registry to use, in your subclass.
<br>
<br>
You should not need to create a new environment for each OCL expression
that you parse, especially if you always use the same resource set and
its same registry. You could create a custom EnvironmentFactory to
create your custom Environments, and use that with an IOclHelper, to
let it create the environments when needed. That would probably be
more than you really need, though. The EnvironmentFactory is more
useful for applications that need to dynamically map their metamodels
to Ecore (such as one might do for SQL or UML) where the environment is
really accessing a non-ecore metamodel.
<br>
<br>
Regarding the bugzilla, I think the statement in your last post is all
that is needed to make the problem plain. We just need to provide a
basic environment implementation that allows a client to plug in an
optional package registry (the default being the shared registry). No
more pluses than that. :-)
<br>
<br>
HTH,
<br>
<br>
Christian
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
</body>
</html>
--------------010005050701070502000908
Content-Type: image/jpeg;
name="moz-screenshot-4.jpg"
Content-Transfer-Encoding: base64
Content-ID: <part1.05030107.09010702@ca.ibm.com>
Content-Disposition: inline;
filename="moz-screenshot-4.jpg"
/9j/4AAQSkZJRgABAQIAJQAlAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsL DBkSEw8UHRof
Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwL DBgNDRgyIRwh
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjL/wAAR
CAB+AOQDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcI CQoL/8QAtRAA
AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS 0fAkM2JyggkK
FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWG
h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW 19jZ2uHi4+Tl
5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcI CQoL/8QAtREA
AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMz UvAVYnLRChYk
NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0 dXZ3eHl6goOE
hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk
5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iiigAooooAKKK838b6z f6J478N2r+LJ
9K0jVftX2kutqqQeVEpTa8kRxuY87ieuBjigD0iivM/CXxKtAlzZeIdTkllf U7uDSbv7G5Go
28bfKyPGnlyPnKgJgk7QASRnpJPiJ4Vj8stqv7toreZ5hbymOFJ/9UZXC7Yt 2QRvK8EHpQB1
FFeb/FTxz/YXhzU4tD1WeDXbDyJXFvaeekayOFCzMY2RMqSwBKscLjg4PQX3 xD8Mab/an2y+
ni/sqWOG9zYznyGkzsJwn3W2nDD5TlefmGQDqKK5+/8AG3h3TNci0W61Dbfy SwwCNIZJAsku
fLRmVSqM2CQGIOBnpzWPp/xT0G6s9cvruO+sLHSbtreSeeymwwBjXJwnytvk x5ZO/A3EDkAA
7iiuX8dXF1p+iw6jb65PpMcV3bxTyIsBQxyzxxuzGVGxtVmIIwB3yKw7y/uX 8IeJdW0Px5d6
kmnW7vHKkFo4SaOFpGXesWx0YPFnAyCpG7kgAHolFcu3iS8TwhJdNHAutxSp p8kRUiJLx5Fi
UkZ3CEu6OD94xMrYyQK5ddR1S38N+ENX1PxzfWcOr+V9slmSyjji32skvylo Pl+dFAyTwcde
aAPUKK4vS7XVdaSG707xzd3Wjs9xi6ht7YSsytHGqgmEoyBkuDuAXO9cbgM1 J4LTXrvTtD1m
912e+tb7SlmuYJ4oV2TuImUx+XEp2geaDuY9V69aAOwooooAKKKKACiiigAo oooAKKKKACii
igAooooAKKKKACuH8SaD4k1Hx3oGuWFrpTWui/aNiT30kbz+dEEOQIWCbSD3 bPtXcUUAcf4h
8PaxqXxA8La3ZpYmx0fz/OE1w6yP5y7G2qIyPlABGW+YnHy9a5/xV8ONY1rU fFSWdzYix8S/
YPOmmd1ktPs5G7agUiXIAIyycnHvXqFFAHlfjL4c69rFx4vXS5dNeDxIliWe 6neJrZrcjgKs
bBwwA5yuMng45j8VfDvxJrX/AAlX2NtKH/CSxWBm866kX7JJb43KuIj5qnAw x2Hn7tesUUAc
Xpfh3XtN8b6vriHTfI1tLNroNK7NatChV0QbQJQw4DkpjOSpxg19M8NeKvDa eJxotxo0r6jq
cuo2hvRLjdK0e5ZAv3Qiq4GN24sp+TaQ3eUUAc/4sstY1GxtrbSbaxl23cFz I13dPDjyZo5Q
oCxvndsIycY4PPSsfWNJ8WatpOt2q2Gh2n9pWj23lRXzkO8kZRp5H+zhmZVW JVUAcbsnhQNv
X9fuNHu9OtLTTH1C4vmkWONZljIKLuPLcdM9+1VP7f8AE3/Qlz/+DGD/ABoA rvoOsf2xDraW
tj9o/eXMuntfP5P2zakCTLL5O/8A49/MUgrtztwucvWfZaJ4ws9L8LWX9naG /wDYOz5/7UmH
n7baSDp9m+X/AFm7v0x3zWx/b/ib/oS5/wDwYwf40f2/4m/6Euf/AMGMH+NA G5PHNZ2Eo0my
tGn3l1hkkMEbMz7nJZUYgklmztOSeeuaz/CFhqWk+FdO0vVIrRJ7G3jtVa1n aVZFRFXedyIV
JIPy4OOOTVP+3/E3/Qlz/wDgxg/xo/t/xN/0Jc//AIMYP8aAOoorl/7f8Tf9 CXP/AODGD/Gj
+3/E3/Qlz/8Agxg/xoA6iiuX/t/xN/0Jc/8A4MYP8aibxP4jV2X/AIQq6JXg 7b2E479jQB1t
Fcj/AMJR4j/6Em8/8C4q1/Dett4g0n7c1r9m/evH5fmiT7p2nkDHUHpn60Aa 9FFFABRRRQAU
UUUAFFFFAHBW0EXif4l+JbPV4ku7DSILSG3splEkBaRWkMrI2R5g5UMMfKSO asTsvw8s3EL3
WqTa3rUcVst3cHMbyoiBXlO5iiiM4OCcbRz96snXdet/+ElnvYPDPjaDVLdW sTqGn6akiywq
5O1fM3IULfMG2hunOOKo3+t6fqOmwWsvg/x4LiG8jv1vV0xfONynSQ5JUnHy 4K7QuAAAqgfQ
RoVJuN17jUU46dEtd+r1016GV0vU2ZfiVcRWlvKNB82X+3W0O5hjvBlZgeDE WUB1I/veXg4H
TkPt/iSzz28dzorxIdaOh3MqXIdUuMttMfALpwCxYJjcMBuccjK+nSWlvCvh z4jRSRam2rPO
mmRb5rsnIkYFSox0CqAvqDRK+nSeft8OfEaLzNYGtJs0yL91c/NyuVPy8jhs /dHvnf6hhmre
z79X/n934i5n3Ors/iPdvdot9okMNsddOhPJBfGVxPjhgpjUFM453A+3ap/+ Fi/8TXy/7K/4
l39u/wBhfaPtH77z9v3vL242buM7845x2rgtHnaPUr261fwt42lhOvy6xaWk GmARBj/q2ckB
94yeA23gdec6X2vSv7V+2f8ACI+P/I/tP+1vsX9mr5P2vbjzM/6zr823ftz2 xxRUy/DqTSp9
Oj0v9+/4ApvudJZ/Eq4ku0ivdB8iL+3Tock0V4JB52PlKAqpZcj5s7cAqRuO Qp/wtK0/4ST+
zPskPlf2x/ZH/H4PtPmdPN8jb/qt/wAu7fn2zxXIj7AIHjOhfEku2qrrAlOl wblugDlh8uMH
IJBBHyjGOc6tlr1vp2pXdzZ+GfiHBb3d4b6eyTTUETzHGW3f6wAlQSofaeRj aStKeBw+rVPp
3f8Am9fw72BSfc2bP4lXEl2kV7oPkRf26dDkmivBIPOx8pQFVLLkfNnbgFSN xyFboPivxdqF
l4muV0Oy1Gaw1OS0t7SC+8o5QxqUDPGAVALvvYgk8bQMY5MfYBA8Z0L4kl21 VdYEp0uDct0A
csPlxg5BIII+UYxznotEs7LxBc63YWdj438OjUWa9eeVfsqxyF4y/ltyd7lV yGzgbwu0Eg5Y
vC0KdGbhTtp92vm/6t97jJt6s6TX/wDkdvCP/XW6/wDRDVITqGvatqkEGr3e lQaZcLagWkcL
NMxhjlLsZY3AGJVUKoGNrEltwCx6/wD8jt4R/wCut1/6Iarlzo+pQX9zd6Hq NpaG8cSXUd3Z
tcK0ioqB12yIVJVVUjJB2qQFO4t88amXba3qOtvYaWlx9guJvt/2i8tkUt/o lwsB8tZAyrvZ
g3zb9qgrySHFiaXWdJ1XQ7GbUftlrdagYjcSIgmkT7LcSFJAqBeHjQhlC5Hy kfKWewfDH2SC
0k0q88jUbXzttzcxecsvnuJJvMQFM73Af5SmGAxhcoa934b1i6ayvTrkB1W1 uxcB3s3NsFEU
sQRYRKCvEzMWLliep2hVUA6iiqemx6lFbsuqXdpcz7yVe1tmgULgcFWkck5z znuOOOblABRR
RQAVzHifUbPSbSe/v7hLe1gZmkkfoBtT8yTwAOSSAK6euP1+91ddTlgsvD11 eQowPnpNGoJK
rwATnjHf/wCuUxo5bwb4+0rxmlwtoHt7qBmLW0xG8x5wrjHUEYzj7pOPQnq/ ht/yJ0f/AF83
H/o1qyPtniP/AKFK8/8AAiL/ABrY+GwI8Hxhhhhc3GRkHH71u4yD+FJAzraK KKoQUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHL6/8A8jt4R/663X/ohqkJ1DXt W1SCDV7vSoNM
uFtQLSOFmmYwxyl2MsbgDEqqFUDG1iS24BY9f/5Hbwj/ANdbr/0Q1WNR0G/a e+k0fUoLJdR5
vEnt5JdzhBGHjaOWNo22KoOGP3FICncWADQ/En9oPa2V1Hi+k+2gvEuI2+y3 AgdsEkruLKwX
5sAkFjjJjh8YRXtvZS6XpGpag9zZQ3zRQ+SjQxSg+WX8yRRk7XGFLY2nOMjM cfhO4tVspLLV
fJu4PtUb3Btw5kjuJRLIwUnas25FIbBQHd+72kKuXL8N4fs+mKp0a8ns9Mt9 Od9W0kXalYQ2
1o18xTGSXbdy2cL0xyAak3jzS45YRDb31zbyWltfNdRQ4hitp2ZVlkZiNqrt 3MDyFJbBCuV3
DqUI1lNLVZHnNu1w7KAViUMFUPzkFiW28c+W/wDdrH/sWx0RLu6uhJd2D6Za 6a9qlh5pZIml
H+riXDBhNgqqAAKeMdJPCej3Gmac02oPPLf3G0O9zKJZViQbIkZx1YKNz4JX zZJSpw1AHQUU
UUAFYWrf60/9dD/6ClbtYWrf60/9dD/6ClKWw0ZtL8Nv+ROj/wCvm4/9GtSU vw2/5E6P/r5u
P/RrUojZ11FFFUSFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBy+ v/8AI7eEf+ut
1/6IarFtrf8AZ39uxa1cY/svdemfZ1s33ujbVH8O2SLHLHydxHziq+v/API7 eEf+ut1/6Iat
DWPD1vrGo6XeTNhrKXewwf3iZWQJwRjEsUEmef8AVbejNkAw7rxp/wAIxYWK eIopDqF2j3Dx
m4tYFgDOSIQ8skaSmMEIShJ+UMwXeuZD4pSfVJZorydtKltNImtTBEoYm5uZ Y8neM7WAjDZ5
C5xhq1L/AEfUv7Zk1TSNRtLWee3jt51u7NrhSsbSMhXbJGVOZXzknPy4xg5y 7bwL9mtorcaj
ujhi023izByI7K5aZNx3csysqkjAyCwGDtAAaz4ulWONdPs75IW1W2sRqHlI 0Lt9rSKaPG4u
vAlXcyKuRw2SmZJviFo1t4lGiTiSKY3C2wd5oFJkYhVHkmTzsFiAG8vBBDZ2 fNRN4RvpALSP
WY4tLTU11JYBZ5lZ/tIuWR5C+ChbdjaqkfJkthg5P4U1JopbG31a0j003p1C OOSxZ5lm8/7S
MyCUKU87tsBKfLuB+egCvpPjUTxPd6zBd6aIE1OR4ykbR+TazohdtjO29QwX CnBIkOCNhrQm
8YRWVvey6ppGpae9tZTXyxTeS7TRRAeYU8uRhkbkGGK53DGcHFeXwPDcG6hm vpDZ3FvqNvsS
MCRVvZI5JDvJIyrK+Pl6MoOSpLF/4U1LWre+XV9WtHnm0y506B7SxaFY1nC7 2ZWlcuQY0xgr
/FnORgA2NK1yHVbi4txa3drPCiS+XdRhGeFywjkABJUMUcbW2uNp3KvGa2rf 60/9dD/6ClXY
dM8rxDe6t52ftNpBbeVt+75TzNuznnPnYxjjb3zxS1b/AFp/66H/ANBSlLYa M2l+G3/InR/9
fNx/6Nakpfht/wAidH/183H/AKNalEbOuoooqiQooooAKKKKACiiigAooooA KKKKACiiigAo
oooAKKKKAOX1/wD5Hbwj/wBdbr/0Q1V7rW9Rg0fWNN+0Y8Qi7ktbE7F589ma 2kVcfNGiH522
n/j3m+9sJNjX/wDkdvCP/XW6/wDRDVoXHh63ufFFprjNiS3iKFMH5nAYRvnP G1ZrgYxz5uTy
q4AMu48WwzjTLy3mktrOG3l1LVRLGGa3t0jdTFIF3FJRKfu9T5EozlSDHrni y6t/D2t/8S6+
0jU4dKur20+1+RJv8pOWHlvIvys8fDYzuGAcHFxfBlj9n8RW7ySCLWkkhby+ GhicOzKCSQT5
s08mSP8AlrtxhVFZcPw9RdO1e2P9h2kl/p81ismlaKtrtEgwWfLsz4wMAMo6 5ydpUA2F8XWc
X2htQs77TYYrSW+SS7iA863j2+ZIFVmddodPldVf5gNuQwBN4gP2EyXmn6rp ci3drFskSFmY
SzLGuGVnjKkkhgG3quTgEoSW+gai2o/bL/WvOmhtJrS0mgtVikRZChZ5Mlke TMUZBCIud3yE
EAZ9j4H+y2M0H2ixt/Mu7O48nTbD7NbL5Eyy5EW9v3j42s+7oqcfLyAGk+NL q8sV87Qb59Rk
u72OOygMAcwwTeWXJaXZ8paNG+bJYkqCvNdJpepQ6tYLdwrIgLvG8cgAaORH KOhwSMqysuQS
DjIJGDXL6j8P4bwxsH024MFxdywR6ppwu4lW5kWWTK71y4kB2sCMIxUhj81d JomlpoujwWEY
gCx7iRb26wRgsxYhI14Vck4HJx1LHLEA0KwtW/1p/wCuh/8AQUrdrjPEfiXR dO1F7O71GGK4
RtzRk5KgquM46dKT2GiSl+G3/InR/wDXzcf+jWrC/wCEx8Pf9BWD9f8ACtz4 aMr+DImUgqbm
cgg8EeY1KIM6+iiiqEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ By+v/wDI7eEf
+ut1/wCiGrqK5fX/APkdvCP/AF1uv/RDV1FABRRRQAUUUUAFFFFABXNeJNTt 9FtbnULr5beI
lpXEBlKqFTnABOBkk8cDJPArpa4zxH4l0XTtRezu9RhiuEbc0ZOSoKrjOOnS kxozNB8d6L4n
nmh0e7W6aFQ0hFiyKoJwMsyAZPOBnJwfQ1tfDhmfwiruxZmurgkk5JPmtXJ6 XrXg3RbVrbTL
mytYHkaVkiUgFmOSen4D0AAGAAK6n4aMr+DImUgqbmcgg8EeY1JAzr6KKKoQ UUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFAEclvDM6vLDG7KCFLKCQDjOPyH5U37J bf8APvF/3wKm
ooAh+yW3/PvF/wB8Cj7Jbf8APvF/3wKmooAh+yW3/PvF/wB8Cj7Jbf8APvF/ 3wKmooAh+yW3
/PvF/wB8Cj7Jbf8APvF/3wKmooAh+yW3/PvF/wB8Cj7Jbf8APvF/3wKmooAh +yW3/PvF/wB8
CpEjSJdsaKg64UYp1FABRRRQAUUUUAFFFFAH/9k=
--------------010005050701070502000908--
--------------020101030304010200030602--
|
|
|
| Re: OCL Question [message #575 is a reply to message #562] |
Wed, 14 September 2005 01:26 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Ed, Christian,
I filed bugzilla http://bugs.eclipse.org/bugs/show_bug.cgi?id=109469 for this.
Cheers
/Eike
Ed Merks schrieb:
> Christian/Eike,
>
> We now have the bugzilla components set up in EMFT so we can handle the
> bugzillas now:
>
>
> Christian W. Damus wrote:
>
>>
>> Hi, Eike,
>>
>> For now, we've been accepting bugzillas in the GMF project for these
>> EMFT-bound components. I guess we'll be transferring them all over to
>> EMFT when it is available.
>>
>> cW
>>
>> Eike Stepper wrote:
>>
>>> hi christian,
>>>
>>> i just tried to file the bugzilla as you proposed, but the EMFT
>>> product is configured for Website component bugs only at the moment...
>>>
>>> cheers
>>> /eike
>>>
>>>
>>>
>>>
>>> cdamus@ca.ibm.com schrieb:
>>>
>>>> Hi, Eike,
>>>>
>>>> I was sloppy in my response: the only interesting parameter to the
>>>> environment would be the package registry, as you say, regardless of
>>>> whether it came from a resource set or otherwise.
>>>>
>>>> If you extend the org.eclipse.emf.ocl.parser.EcoreEnvironment class,
>>>> you can override the "EPackage lookupPackage(List path)" method to
>>>> fall back to a registry of your choosing. The "default package" is,
>>>> in a sense, a "starting package". It represents the OCL's optional
>>>> context package, which is the package in which unqualified
>>>> classifier names are expected to be found and in which unqualified
>>>> or partially qualified package names can be found. The parser's
>>>> implementation extends that a bit by trying to find names in the
>>>> super-package chain if they cannot be found in the default package.
>>>> The final fall-back is to look for an absolute package path in the
>>>> global registry. This is where you can can customize the registry
>>>> to use, in your subclass.
>>>>
>>>> You should not need to create a new environment for each OCL
>>>> expression that you parse, especially if you always use the same
>>>> resource set and its same registry. You could create a custom
>>>> EnvironmentFactory to create your custom Environments, and use that
>>>> with an IOclHelper, to let it create the environments when needed.
>>>> That would probably be more than you really need, though. The
>>>> EnvironmentFactory is more useful for applications that need to
>>>> dynamically map their metamodels to Ecore (such as one might do for
>>>> SQL or UML) where the environment is really accessing a non-ecore
>>>> metamodel.
>>>>
>>>> Regarding the bugzilla, I think the statement in your last post is
>>>> all that is needed to make the problem plain. We just need to
>>>> provide a basic environment implementation that allows a client to
>>>> plug in an optional package registry (the default being the shared
>>>> registry). No more pluses than that. :-)
>>>>
>>>> HTH,
>>>>
>>>> Christian
>>>
>
|
|
|
| Re: OCL Question [message #560837 is a reply to message #449] |
Mon, 12 September 2005 12:19 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
(likewise copied from the GMF newsgroup)
Hi, Eike,
I recently committed a refactoring of the OCL parser's environment
infrastructure that allows clients to provide their own Environment
implementations that look up package names and other names.
Have a look at the org.eclipse.emf.ocl.parser.EnvironmentFactory and the
org.eclipse.emf.ocl.helper.IOclHelper interfaces for details.
Of course, creating your own environment implementation isn't the greatest
because everybody would want resource-set-specific package lookup, not
just you. That should be supported by the default Ecore environment
implementation. The only trouble is, that currently the OCL parser knows
nothing about resource sets, so the creation of environments would need to
be (optionally) parameterized by a resource set. This would be worth
raising an enhancement for in Bugzilla (hint, hint).
Christian
|
|
|
| Re: OCL Question [message #560850 is a reply to message #458] |
Mon, 12 September 2005 13:59 |
| Eclipse User |
|
|
|
hi christian,
as i understand the new code, it allows to specify a single package
for the EcoreEnvironment. is this considered to be a "starting"
package? what about the other packages of my registry, are they found
by following associations to referenced EClasses?
am i expected to provide a new EcoreEnvironment for each validation
in my model?
i'm also not sure about your comment on resource sets. ok, a resource set
has associated a local EPackage.Registry, but i think in the context of
an OCL environment only the package registry itself is of importance,
not the containing resource set. what do you think?
i'd like to open a bugzilla, but at the moment i could only explain
my problem. i need my package registry being used by the OCL parser/evaluator.
which is the "plus" of flexibility that you have in mind?
cheers
/eike
cdamus@ca.ibm.com schrieb:
> (likewise copied from the GMF newsgroup)
>
> Hi, Eike,
>
> I recently committed a refactoring of the OCL parser's environment
> infrastructure that allows clients to provide their own Environment
> implementations that look up package names and other names.
>
> Have a look at the org.eclipse.emf.ocl.parser.EnvironmentFactory and the
> org.eclipse.emf.ocl.helper.IOclHelper interfaces for details.
>
> Of course, creating your own environment implementation isn't the greatest
>
> because everybody would want resource-set-specific package lookup, not
> just you. That should be supported by the default Ecore environment
> implementation. The only trouble is, that currently the OCL parser knows
> nothing about resource sets, so the creation of environments would need to
>
> be (optionally) parameterized by a resource set. This would be worth
> raising an enhancement for in Bugzilla (hint, hint).
>
> Christian
>
|
|
|
| Re: OCL Question [message #560863 is a reply to message #472] |
Mon, 12 September 2005 15:00 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Eike,
I was sloppy in my response: the only interesting parameter to the
environment would be the package registry, as you say, regardless of
whether it came from a resource set or otherwise.
If you extend the org.eclipse.emf.ocl.parser.EcoreEnvironment class, you
can override the "EPackage lookupPackage(List path)" method to fall back
to a registry of your choosing. The "default package" is, in a sense, a
"starting package". It represents the OCL's optional context package,
which is the package in which unqualified classifier names are expected to
be found and in which unqualified or partially qualified package names can
be found. The parser's implementation extends that a bit by trying to
find names in the super-package chain if they cannot be found in the
default package. The final fall-back is to look for an absolute package
path in the global registry. This is where you can can customize the
registry to use, in your subclass.
You should not need to create a new environment for each OCL expression
that you parse, especially if you always use the same resource set and its
same registry. You could create a custom EnvironmentFactory to create
your custom Environments, and use that with an IOclHelper, to let it
create the environments when needed. That would probably be more than you
really need, though. The EnvironmentFactory is more useful for
applications that need to dynamically map their metamodels to Ecore (such
as one might do for SQL or UML) where the environment is really accessing
a non-ecore metamodel.
Regarding the bugzilla, I think the statement in your last post is all
that is needed to make the problem plain. We just need to provide a basic
environment implementation that allows a client to plug in an optional
package registry (the default being the shared registry). No more pluses
than that. :-)
HTH,
Christian
|
|
|
| Re: OCL Question [message #560875 is a reply to message #484] |
Tue, 13 September 2005 01:45 |
| Eclipse User |
|
|
|
hi christian,
i just tried to file the bugzilla as you proposed, but the EMFT
product is configured for Website component bugs only at the moment...
cheers
/eike
cdamus@ca.ibm.com schrieb:
> Hi, Eike,
>
> I was sloppy in my response: the only interesting parameter to the
> environment would be the package registry, as you say, regardless of
> whether it came from a resource set or otherwise.
>
> If you extend the org.eclipse.emf.ocl.parser.EcoreEnvironment class, you
> can override the "EPackage lookupPackage(List path)" method to fall back
> to a registry of your choosing. The "default package" is, in a sense, a
> "starting package". It represents the OCL's optional context package,
> which is the package in which unqualified classifier names are expected to
> be found and in which unqualified or partially qualified package names can
> be found. The parser's implementation extends that a bit by trying to
> find names in the super-package chain if they cannot be found in the
> default package. The final fall-back is to look for an absolute package
> path in the global registry. This is where you can can customize the
> registry to use, in your subclass.
>
> You should not need to create a new environment for each OCL expression
> that you parse, especially if you always use the same resource set and its
> same registry. You could create a custom EnvironmentFactory to create
> your custom Environments, and use that with an IOclHelper, to let it
> create the environments when needed. That would probably be more than you
> really need, though. The EnvironmentFactory is more useful for
> applications that need to dynamically map their metamodels to Ecore (such
> as one might do for SQL or UML) where the environment is really accessing
> a non-ecore metamodel.
>
> Regarding the bugzilla, I think the statement in your last post is all
> that is needed to make the problem plain. We just need to provide a basic
> environment implementation that allows a client to plug in an optional
> package registry (the default being the shared registry). No more pluses
> than that. :-)
>
> HTH,
>
> Christian
|
|
|
| Re: OCL Question [message #560889 is a reply to message #498] |
Tue, 13 September 2005 07:21 |
| Eclipse User |
|
|
|
Eike,
Yes, we have no appropriate bugzilla components yet. Even the CVS
infrastructure for these components isn't set up quite right yet. :-(
I'll work at getting this improved as soon as possible.
Eike Stepper wrote:
> hi christian,
>
> i just tried to file the bugzilla as you proposed, but the EMFT
> product is configured for Website component bugs only at the moment...
>
> cheers
> /eike
>
>
>
>
> cdamus@ca.ibm.com schrieb:
>
>> Hi, Eike,
>>
>> I was sloppy in my response: the only interesting parameter to the
>> environment would be the package registry, as you say, regardless of
>> whether it came from a resource set or otherwise.
>>
>> If you extend the org.eclipse.emf.ocl.parser.EcoreEnvironment class,
>> you can override the "EPackage lookupPackage(List path)" method to
>> fall back to a registry of your choosing. The "default package" is,
>> in a sense, a "starting package". It represents the OCL's optional
>> context package, which is the package in which unqualified classifier
>> names are expected to be found and in which unqualified or partially
>> qualified package names can be found. The parser's implementation
>> extends that a bit by trying to find names in the super-package chain
>> if they cannot be found in the default package. The final fall-back
>> is to look for an absolute package path in the global registry. This
>> is where you can can customize the registry to use, in your subclass.
>>
>> You should not need to create a new environment for each OCL
>> expression that you parse, especially if you always use the same
>> resource set and its same registry. You could create a custom
>> EnvironmentFactory to create your custom Environments, and use that
>> with an IOclHelper, to let it create the environments when needed.
>> That would probably be more than you really need, though. The
>> EnvironmentFactory is more useful for applications that need to
>> dynamically map their metamodels to Ecore (such as one might do for
>> SQL or UML) where the environment is really accessing a non-ecore
>> metamodel.
>>
>> Regarding the bugzilla, I think the statement in your last post is
>> all that is needed to make the problem plain. We just need to
>> provide a basic environment implementation that allows a client to
>> plug in an optional package registry (the default being the shared
>> registry). No more pluses than that. :-)
>>
>> HTH,
>>
>> Christian
>
|
|
|
| Re: OCL Question [message #560902 is a reply to message #510] |
Tue, 13 September 2005 07:26 |
| Eclipse User |
|
|
|
Ed Merks schrieb:
> Eike,
>
> Yes, we have no appropriate bugzilla components yet. Even the CVS
> infrastructure for these components isn't set up quite right yet. :-(
> I'll work at getting this improved as soon as possible.
Btw. did I get you right in that you have everything you need for CDO approval?
Cheers
/Eike
|
|
|
| Re: OCL Question [message #560915 is a reply to message #523] |
Tue, 13 September 2005 07:31 |
| Eclipse User |
|
|
|
Eike,
I'm asking that very same question, but yes I believe and hope that I
have all I need to set up your components in CVS. Just keep reminding
yourself that patience is a virtue; I know I remind myself often of
that, and yet I often don't feel so virtuous....
Eike Stepper wrote:
> Ed Merks schrieb:
>
>> Eike,
>>
>> Yes, we have no appropriate bugzilla components yet. Even the CVS
>> infrastructure for these components isn't set up quite right yet. :-(
>> I'll work at getting this improved as soon as possible.
>
>
> Btw. did I get you right in that you have everything you need for CDO
> approval?
>
> Cheers
> /Eike
|
|
|
| Re: OCL Question [message #560928 is a reply to message #498] |
Tue, 13 September 2005 08:57 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Eike,
For now, we've been accepting bugzillas in the GMF project for these
EMFT-bound components. I guess we'll be transferring them all over to
EMFT when it is available.
cW
Eike Stepper wrote:
> hi christian,
>
> i just tried to file the bugzilla as you proposed, but the EMFT
> product is configured for Website component bugs only at the moment...
>
> cheers
> /eike
>
>
>
>
> cdamus@ca.ibm.com schrieb:
>
>> Hi, Eike,
>>
>> I was sloppy in my response: the only interesting parameter to the
>> environment would be the package registry, as you say, regardless of
>> whether it came from a resource set or otherwise.
>>
>> If you extend the org.eclipse.emf.ocl.parser.EcoreEnvironment class,
>> you can override the "EPackage lookupPackage(List path)" method to
>> fall back to a registry of your choosing. The "default package" is,
>> in a sense, a "starting package". It represents the OCL's optional
>> context package, which is the package in which unqualified classifier
>> names are expected to be found and in which unqualified or partially
>> qualified package names can be found. The parser's implementation
>> extends that a bit by trying to find names in the super-package chain
>> if they cannot be found in the default package. The final fall-back
>> is to look for an absolute package path in the global registry. This
>> is where you can can customize the registry to use, in your subclass.
>>
>> You should not need to create a new environment for each OCL
>> expression that you parse, especially if you always use the same
>> resource set and its same registry. You could create a custom
>> EnvironmentFactory to create your custom Environments, and use that
>> with an IOclHelper, to let it create the environments when needed.
>> That would probably be more than you really need, though. The
>> EnvironmentFactory is more useful for applications that need to
>> dynamically map their metamodels to Ecore (such as one might do for
>> SQL or UML) where the environment is really accessing a non-ecore
>> metamodel.
>>
>> Regarding the bugzilla, I think the statement in your last post is all
>> that is needed to make the problem plain. We just need to provide a
>> basic environment implementation that allows a client to plug in an
>> optional package registry (the default being the shared registry). No
>> more pluses than that. :-)
>>
>> HTH,
>>
>> Christian
|
|
|
| Re: OCL Question [message #560940 is a reply to message #549] |
Tue, 13 September 2005 11:31 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------020101030304010200030602
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Christian/Eike,
We now have the bugzilla components set up in EMFT so we can handle the
bugzillas now:
Christian W. Damus wrote:
>
> Hi, Eike,
>
> For now, we've been accepting bugzillas in the GMF project for these
> EMFT-bound components. I guess we'll be transferring them all over to
> EMFT when it is available.
>
> cW
>
> Eike Stepper wrote:
>
>> hi christian,
>>
>> i just tried to file the bugzilla as you proposed, but the EMFT
>> product is configured for Website component bugs only at the moment...
>>
>> cheers
>> /eike
>>
>>
>>
>>
>> cdamus@ca.ibm.com schrieb:
>>
>>> Hi, Eike,
>>>
>>> I was sloppy in my response: the only interesting parameter to the
>>> environment would be the package registry, as you say, regardless of
>>> whether it came from a resource set or otherwise.
>>>
>>> If you extend the org.eclipse.emf.ocl.parser.EcoreEnvironment class,
>>> you can override the "EPackage lookupPackage(List path)" method to
>>> fall back to a registry of your choosing. The "default package" is,
>>> in a sense, a "starting package". It represents the OCL's optional
>>> context package, which is the package in which unqualified
>>> classifier names are expected to be found and in which unqualified
>>> or partially qualified package names can be found. The parser's
>>> implementation extends that a bit by trying to find names in the
>>> super-package chain if they cannot be found in the default package.
>>> The final fall-back is to look for an absolute package path in the
>>> global registry. This is where you can can customize the registry
>>> to use, in your subclass.
>>>
>>> You should not need to create a new environment for each OCL
>>> expression that you parse, especially if you always use the same
>>> resource set and its same registry. You could create a custom
>>> EnvironmentFactory to create your custom Environments, and use that
>>> with an IOclHelper, to let it create the environments when needed.
>>> That would probably be more than you really need, though. The
>>> EnvironmentFactory is more useful for applications that need to
>>> dynamically map their metamodels to Ecore (such as one might do for
>>> SQL or UML) where the environment is really accessing a non-ecore
>>> metamodel.
>>>
>>> Regarding the bugzilla, I think the statement in your last post is
>>> all that is needed to make the problem plain. We just need to
>>> provide a basic environment implementation that allows a client to
>>> plug in an optional package registry (the default being the shared
>>> registry). No more pluses than that. :-)
>>>
>>> HTH,
>>>
>>> Christian
>>
--------------020101030304010200030602
Content-Type: multipart/related;
boundary="------------010005050701070502000908"
--------------010005050701070502000908
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Christian/Eike,<br>
<br>
We now have the bugzilla components set up in EMFT so we can handle the
bugzillas now:<br>
<blockquote><img src="cid:part1.05030107.09010702@ca.ibm.com" alt=""><br>
</blockquote>
Christian W. Damus wrote:
<blockquote cite="middg6i9s$dl8$1@news.eclipse.org" type="cite"><br>
Hi, Eike,
<br>
<br>
For now, we've been accepting bugzillas in the GMF project for these
EMFT-bound components. I guess we'll be transferring them all over to
EMFT when it is available.
<br>
<br>
cW
<br>
<br>
Eike Stepper wrote:
<br>
<blockquote type="cite">hi christian,
<br>
<br>
i just tried to file the bugzilla as you proposed, but the EMFT
<br>
product is configured for Website component bugs only at the moment...
<br>
<br>
cheers
<br>
/eike
<br>
<br>
<br>
<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:cdamus@ca.ibm.com">cdamus@ca.ibm.com</a> schrieb:
<br>
<br>
<blockquote type="cite">Hi, Eike,
<br>
<br>
I was sloppy in my response: the only interesting parameter to the
environment would be the package registry, as you say, regardless of
whether it came from a resource set or otherwise.
<br>
<br>
If you extend the org.eclipse.emf.ocl.parser.EcoreEnvironment class,
you can override the "EPackage lookupPackage(List path)" method to fall
back to a registry of your choosing. The "default package" is, in a
sense, a "starting package". It represents the OCL's optional context
package, which is the package in which unqualified classifier names are
expected to be found and in which unqualified or partially qualified
package names can be found. The parser's implementation extends that a
bit by trying to find names in the super-package chain if they cannot
be found in the default package. The final fall-back is to look for an
absolute package path in the global registry. This is where you can
can customize the registry to use, in your subclass.
<br>
<br>
You should not need to create a new environment for each OCL expression
that you parse, especially if you always use the same resource set and
its same registry. You could create a custom EnvironmentFactory to
create your custom Environments, and use that with an IOclHelper, to
let it create the environments when needed. That would probably be
more than you really need, though. The EnvironmentFactory is more
useful for applications that need to dynamically map their metamodels
to Ecore (such as one might do for SQL or UML) where the environment is
really accessing a non-ecore metamodel.
<br>
<br>
Regarding the bugzilla, I think the statement in your last post is all
that is needed to make the problem plain. We just need to provide a
basic environment implementation that allows a client to plug in an
optional package registry (the default being the shared registry). No
more pluses than that. :-)
<br>
<br>
HTH,
<br>
<br>
Christian
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
</body>
</html>
--------------010005050701070502000908
Content-Type: image/jpeg;
name="moz-screenshot-4.jpg"
Content-Transfer-Encoding: base64
Content-ID: <part1.05030107.09010702@ca.ibm.com>
Content-Disposition: inline;
filename="moz-screenshot-4.jpg"
/9j/4AAQSkZJRgABAQIAJQAlAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsL DBkSEw8UHRof
Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwL DBgNDRgyIRwh
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjL/wAAR
CAB+AOQDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcI CQoL/8QAtRAA
AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS 0fAkM2JyggkK
FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWG
h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW 19jZ2uHi4+Tl
5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcI CQoL/8QAtREA
AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMz UvAVYnLRChYk
NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0 dXZ3eHl6goOE
hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk
5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iiigAooooAKKK838b6z f6J478N2r+LJ
9K0jVftX2kutqqQeVEpTa8kRxuY87ieuBjigD0iivM/CXxKtAlzZeIdTkllf U7uDSbv7G5Go
28bfKyPGnlyPnKgJgk7QASRnpJPiJ4Vj8stqv7toreZ5hbymOFJ/9UZXC7Yt 2QRvK8EHpQB1
FFeb/FTxz/YXhzU4tD1WeDXbDyJXFvaeekayOFCzMY2RMqSwBKscLjg4PQX3 xD8Mab/an2y+
ni/sqWOG9zYznyGkzsJwn3W2nDD5TlefmGQDqKK5+/8AG3h3TNci0W61Dbfy SwwCNIZJAsku
fLRmVSqM2CQGIOBnpzWPp/xT0G6s9cvruO+sLHSbtreSeeymwwBjXJwnytvk x5ZO/A3EDkAA
7iiuX8dXF1p+iw6jb65PpMcV3bxTyIsBQxyzxxuzGVGxtVmIIwB3yKw7y/uX 8IeJdW0Px5d6
kmnW7vHKkFo4SaOFpGXesWx0YPFnAyCpG7kgAHolFcu3iS8TwhJdNHAutxSp p8kRUiJLx5Fi
UkZ3CEu6OD94xMrYyQK5ddR1S38N+ENX1PxzfWcOr+V9slmSyjji32skvylo Pl+dFAyTwcde
aAPUKK4vS7XVdaSG707xzd3Wjs9xi6ht7YSsytHGqgmEoyBkuDuAXO9cbgM1 J4LTXrvTtD1m
912e+tb7SlmuYJ4oV2TuImUx+XEp2geaDuY9V69aAOwooooAKKKKACiiigAo oooAKKKKACii
igAooooAKKKKACuH8SaD4k1Hx3oGuWFrpTWui/aNiT30kbz+dEEOQIWCbSD3 bPtXcUUAcf4h
8PaxqXxA8La3ZpYmx0fz/OE1w6yP5y7G2qIyPlABGW+YnHy9a5/xV8ONY1rU fFSWdzYix8S/
YPOmmd1ktPs5G7agUiXIAIyycnHvXqFFAHlfjL4c69rFx4vXS5dNeDxIliWe 6neJrZrcjgKs
bBwwA5yuMng45j8VfDvxJrX/AAlX2NtKH/CSxWBm866kX7JJb43KuIj5qnAw x2Hn7tesUUAc
Xpfh3XtN8b6vriHTfI1tLNroNK7NatChV0QbQJQw4DkpjOSpxg19M8NeKvDa eJxotxo0r6jq
cuo2hvRLjdK0e5ZAv3Qiq4GN24sp+TaQ3eUUAc/4sstY1GxtrbSbaxl23cFz I13dPDjyZo5Q
oCxvndsIycY4PPSsfWNJ8WatpOt2q2Gh2n9pWj23lRXzkO8kZRp5H+zhmZVW JVUAcbsnhQNv
X9fuNHu9OtLTTH1C4vmkWONZljIKLuPLcdM9+1VP7f8AE3/Qlz/+DGD/ABoA rvoOsf2xDraW
tj9o/eXMuntfP5P2zakCTLL5O/8A49/MUgrtztwucvWfZaJ4ws9L8LWX9naG /wDYOz5/7UmH
n7baSDp9m+X/AFm7v0x3zWx/b/ib/oS5/wDwYwf40f2/4m/6Euf/AMGMH+NA G5PHNZ2Eo0my
tGn3l1hkkMEbMz7nJZUYgklmztOSeeuaz/CFhqWk+FdO0vVIrRJ7G3jtVa1n aVZFRFXedyIV
JIPy4OOOTVP+3/E3/Qlz/wDgxg/xo/t/xN/0Jc//AIMYP8aAOoorl/7f8Tf9 CXP/AODGD/Gj
+3/E3/Qlz/8Agxg/xoA6iiuX/t/xN/0Jc/8A4MYP8aibxP4jV2X/AIQq6JXg 7b2E479jQB1t
Fcj/AMJR4j/6Em8/8C4q1/Dett4g0n7c1r9m/evH5fmiT7p2nkDHUHpn60Aa 9FFFABRRRQAU
UUUAFFFFAHBW0EXif4l+JbPV4ku7DSILSG3splEkBaRWkMrI2R5g5UMMfKSO asTsvw8s3EL3
WqTa3rUcVst3cHMbyoiBXlO5iiiM4OCcbRz96snXdet/+ElnvYPDPjaDVLdW sTqGn6akiywq
5O1fM3IULfMG2hunOOKo3+t6fqOmwWsvg/x4LiG8jv1vV0xfONynSQ5JUnHy 4K7QuAAAqgfQ
RoVJuN17jUU46dEtd+r1016GV0vU2ZfiVcRWlvKNB82X+3W0O5hjvBlZgeDE WUB1I/veXg4H
TkPt/iSzz28dzorxIdaOh3MqXIdUuMttMfALpwCxYJjcMBuccjK+nSWlvCvh z4jRSRam2rPO
mmRb5rsnIkYFSox0CqAvqDRK+nSeft8OfEaLzNYGtJs0yL91c/NyuVPy8jhs /dHvnf6hhmre
z79X/n934i5n3Ors/iPdvdot9okMNsddOhPJBfGVxPjhgpjUFM453A+3ap/+ Fi/8TXy/7K/4
l39u/wBhfaPtH77z9v3vL242buM7845x2rgtHnaPUr261fwt42lhOvy6xaWk GmARBj/q2ckB
94yeA23gdec6X2vSv7V+2f8ACI+P/I/tP+1vsX9mr5P2vbjzM/6zr823ftz2 xxRUy/DqTSp9
Oj0v9+/4ApvudJZ/Eq4ku0ivdB8iL+3Tock0V4JB52PlKAqpZcj5s7cAqRuO Qp/wtK0/4ST+
zPskPlf2x/ZH/H4PtPmdPN8jb/qt/wAu7fn2zxXIj7AIHjOhfEku2qrrAlOl wblugDlh8uMH
IJBBHyjGOc6tlr1vp2pXdzZ+GfiHBb3d4b6eyTTUETzHGW3f6wAlQSofaeRj aStKeBw+rVPp
3f8Am9fw72BSfc2bP4lXEl2kV7oPkRf26dDkmivBIPOx8pQFVLLkfNnbgFSN xyFboPivxdqF
l4muV0Oy1Gaw1OS0t7SC+8o5QxqUDPGAVALvvYgk8bQMY5MfYBA8Z0L4kl21 VdYEp0uDct0A
csPlxg5BIII+UYxznotEs7LxBc63YWdj438OjUWa9eeVfsqxyF4y/ltyd7lV yGzgbwu0Eg5Y
vC0KdGbhTtp92vm/6t97jJt6s6TX/wDkdvCP/XW6/wDRDVITqGvatqkEGr3e lQaZcLagWkcL
NMxhjlLsZY3AGJVUKoGNrEltwCx6/wD8jt4R/wCut1/6Iarlzo+pQX9zd6Hq NpaG8cSXUd3Z
tcK0ioqB12yIVJVVUjJB2qQFO4t88amXba3qOtvYaWlx9guJvt/2i8tkUt/o lwsB8tZAyrvZ
g3zb9qgrySHFiaXWdJ1XQ7GbUftlrdagYjcSIgmkT7LcSFJAqBeHjQhlC5Hy kfKWewfDH2SC
0k0q88jUbXzttzcxecsvnuJJvMQFM73Af5SmGAxhcoa934b1i6ayvTrkB1W1 uxcB3s3NsFEU
sQRYRKCvEzMWLliep2hVUA6iiqemx6lFbsuqXdpcz7yVe1tmgULgcFWkck5z znuOOOblABRR
RQAVzHifUbPSbSe/v7hLe1gZmkkfoBtT8yTwAOSSAK6euP1+91ddTlgsvD11 eQowPnpNGoJK
rwATnjHf/wCuUxo5bwb4+0rxmlwtoHt7qBmLW0xG8x5wrjHUEYzj7pOPQnq/ ht/yJ0f/AF83
H/o1qyPtniP/AKFK8/8AAiL/ABrY+GwI8Hxhhhhc3GRkHH71u4yD+FJAzraK KKoQUUUUAFFF
FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHL6/8A8jt4R/663X/ohqkJ1DXt W1SCDV7vSoNM
uFtQLSOFmmYwxyl2MsbgDEqqFUDG1iS24BY9f/5Hbwj/ANdbr/0Q1WNR0G/a e+k0fUoLJdR5
vEnt5JdzhBGHjaOWNo22KoOGP3FICncWADQ/En9oPa2V1Hi+k+2gvEuI2+y3 AgdsEkruLKwX
5sAkFjjJjh8YRXtvZS6XpGpag9zZQ3zRQ+SjQxSg+WX8yRRk7XGFLY2nOMjM cfhO4tVspLLV
fJu4PtUb3Btw5kjuJRLIwUnas25FIbBQHd+72kKuXL8N4fs+mKp0a8ns9Mt9 Od9W0kXalYQ2
1o18xTGSXbdy2cL0xyAak3jzS45YRDb31zbyWltfNdRQ4hitp2ZVlkZiNqrt 3MDyFJbBCuV3
DqUI1lNLVZHnNu1w7KAViUMFUPzkFiW28c+W/wDdrH/sWx0RLu6uhJd2D6Za 6a9qlh5pZIml
H+riXDBhNgqqAAKeMdJPCej3Gmac02oPPLf3G0O9zKJZViQbIkZx1YKNz4JX zZJSpw1AHQUU
UUAFYWrf60/9dD/6ClbtYWrf60/9dD/6ClKWw0ZtL8Nv+ROj/wCvm4/9GtSU vw2/5E6P/r5u
P/RrUojZ11FFFUSFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBy+ v/8AI7eEf+ut
1/6IarFtrf8AZ39uxa1cY/svdemfZ1s33ujbVH8O2SLHLHydxHziq+v/API7 eEf+ut1/6Iat
DWPD1vrGo6XeTNhrKXewwf3iZWQJwRjEsUEmef8AVbejNkAw7rxp/wAIxYWK eIopDqF2j3Dx
m4tYFgDOSIQ8skaSmMEIShJ+UMwXeuZD4pSfVJZorydtKltNImtTBEoYm5uZ Y8neM7WAjDZ5
C5xhq1L/AEfUv7Zk1TSNRtLWee3jt51u7NrhSsbSMhXbJGVOZXzknPy4xg5y 7bwL9mtorcaj
ujhi023izByI7K5aZNx3csysqkjAyCwGDtAAaz4ulWONdPs75IW1W2sRqHlI 0Lt9rSKaPG4u
vAlXcyKuRw2SmZJviFo1t4lGiTiSKY3C2wd5oFJkYhVHkmTzsFiAG8vBBDZ2 fNRN4RvpALSP
WY4tLTU11JYBZ5lZ/tIuWR5C+ChbdjaqkfJkthg5P4U1JopbG31a0j003p1C OOSxZ5lm8/7S
MyCUKU87tsBKfLuB+egCvpPjUTxPd6zBd6aIE1OR4ykbR+TazohdtjO29QwX CnBIkOCNhrQm
8YRWVvey6ppGpae9tZTXyxTeS7TRRAeYU8uRhkbkGGK53DGcHFeXwPDcG6hm vpDZ3FvqNvsS
MCRVvZI5JDvJIyrK+Pl6MoOSpLF/4U1LWre+XV9WtHnm0y506B7SxaFY1nC7 2ZWlcuQY0xgr
/FnORgA2NK1yHVbi4txa3drPCiS+XdRhGeFywjkABJUMUcbW2uNp3KvGa2rf 60/9dD/6ClXY
dM8rxDe6t52ftNpBbeVt+75TzNuznnPnYxjjb3zxS1b/AFp/66H/ANBSlLYa M2l+G3/InR/9
fNx/6Nakpfht/wAidH/183H/AKNalEbOuoooqiQooooAKKKKACiiigAooooA KKKKACiiigAo
oooAKKKKAOX1/wD5Hbwj/wBdbr/0Q1V7rW9Rg0fWNN+0Y8Qi7ktbE7F589ma 2kVcfNGiH522
n/j3m+9sJNjX/wDkdvCP/XW6/wDRDVoXHh63ufFFprjNiS3iKFMH5nAYRvnP G1ZrgYxz5uTy
q4AMu48WwzjTLy3mktrOG3l1LVRLGGa3t0jdTFIF3FJRKfu9T5EozlSDHrni y6t/D2t/8S6+
0jU4dKur20+1+RJv8pOWHlvIvys8fDYzuGAcHFxfBlj9n8RW7ySCLWkkhby+ GhicOzKCSQT5
s08mSP8AlrtxhVFZcPw9RdO1e2P9h2kl/p81ismlaKtrtEgwWfLsz4wMAMo6 5ydpUA2F8XWc
X2htQs77TYYrSW+SS7iA863j2+ZIFVmddodPldVf5gNuQwBN4gP2EyXmn6rp ci3drFskSFmY
SzLGuGVnjKkkhgG3quTgEoSW+gai2o/bL/WvOmhtJrS0mgtVikRZChZ5Mlke TMUZBCIud3yE
EAZ9j4H+y2M0H2ixt/Mu7O48nTbD7NbL5Eyy5EW9v3j42s+7oqcfLyAGk+NL q8sV87Qb59Rk
u72OOygMAcwwTeWXJaXZ8paNG+bJYkqCvNdJpepQ6tYLdwrIgLvG8cgAaORH KOhwSMqysuQS
DjIJGDXL6j8P4bwxsH024MFxdywR6ppwu4lW5kWWTK71y4kB2sCMIxUhj81d JomlpoujwWEY
gCx7iRb26wRgsxYhI14Vck4HJx1LHLEA0KwtW/1p/wCuh/8AQUrdrjPEfiXR dO1F7O71GGK4
RtzRk5KgquM46dKT2GiSl+G3/InR/wDXzcf+jWrC/wCEx8Pf9BWD9f8ACtz4 aMr+DImUgqbm
cgg8EeY1KIM6+iiiqEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ By+v/wDI7eEf
+ut1/wCiGrqK5fX/APkdvCP/AF1uv/RDV1FABRRRQAUUUUAFFFFABXNeJNTt 9FtbnULr5beI
lpXEBlKqFTnABOBkk8cDJPArpa4zxH4l0XTtRezu9RhiuEbc0ZOSoKrjOOnS kxozNB8d6L4n
nmh0e7W6aFQ0hFiyKoJwMsyAZPOBnJwfQ1tfDhmfwiruxZmurgkk5JPmtXJ6 XrXg3RbVrbTL
mytYHkaVkiUgFmOSen4D0AAGAAK6n4aMr+DImUgqbmcgg8EeY1JAzr6KKKoQ UUUUAFFFFABR
RRQAUUUUAFFFFABRRRQAUUUUAFFFFAEclvDM6vLDG7KCFLKCQDjOPyH5U37J bf8APvF/3wKm
ooAh+yW3/PvF/wB8Cj7Jbf8APvF/3wKmooAh+yW3/PvF/wB8Cj7Jbf8APvF/ 3wKmooAh+yW3
/PvF/wB8Cj7Jbf8APvF/3wKmooAh+yW3/PvF/wB8Cj7Jbf8APvF/3wKmooAh +yW3/PvF/wB8
CpEjSJdsaKg64UYp1FABRRRQAUUUUAFFFFAH/9k=
--------------010005050701070502000908--
--------------020101030304010200030602--
|
|
|
| Re: OCL Question [message #560953 is a reply to message #562] |
Wed, 14 September 2005 01:26 |
| Eclipse User |
|
|
|
Ed, Christian,
I filed bugzilla http://bugs.eclipse.org/bugs/show_bug.cgi?id=109469 for this.
Cheers
/Eike
Ed Merks schrieb:
> Christian/Eike,
>
> We now have the bugzilla components set up in EMFT so we can handle the
> bugzillas now:
>
>
> Christian W. Damus wrote:
>
>>
>> Hi, Eike,
>>
>> For now, we've been accepting bugzillas in the GMF project for these
>> EMFT-bound components. I guess we'll be transferring them all over to
>> EMFT when it is available.
>>
>> cW
>>
>> Eike Stepper wrote:
>>
>>> hi christian,
>>>
>>> i just tried to file the bugzilla as you proposed, but the EMFT
>>> product is configured for Website component bugs only at the moment...
>>>
>>> cheers
>>> /eike
>>>
>>>
>>>
>>>
>>> cdamus@ca.ibm.com schrieb:
>>>
>>>> Hi, Eike,
>>>>
>>>> I was sloppy in my response: the only interesting parameter to the
>>>> environment would be the package registry, as you say, regardless of
>>>> whether it came from a resource set or otherwise.
>>>>
>>>> If you extend the org.eclipse.emf.ocl.parser.EcoreEnvironment class,
>>>> you can override the "EPackage lookupPackage(List path)" method to
>>>> fall back to a registry of your choosing. The "default package" is,
>>>> in a sense, a "starting package". It represents the OCL's optional
>>>> context package, which is the package in which unqualified
>>>> classifier names are expected to be found and in which unqualified
>>>> or partially qualified package names can be found. The parser's
>>>> implementation extends that a bit by trying to find names in the
>>>> super-package chain if they cannot be found in the default package.
>>>> The final fall-back is to look for an absolute package path in the
>>>> global registry. This is where you can can customize the registry
>>>> to use, in your subclass.
>>>>
>>>> You should not need to create a new environment for each OCL
>>>> expression that you parse, especially if you always use the same
>>>> resource set and its same registry. You could create a custom
>>>> EnvironmentFactory to create your custom Environments, and use that
>>>> with an IOclHelper, to let it create the environments when needed.
>>>> That would probably be more than you really need, though. The
>>>> EnvironmentFactory is more useful for applications that need to
>>>> dynamically map their metamodels to Ecore (such as one might do for
>>>> SQL or UML) where the environment is really accessing a non-ecore
>>>> metamodel.
>>>>
>>>> Regarding the bugzilla, I think the statement in your last post is
>>>> all that is needed to make the problem plain. We just need to
>>>> provide a basic environment implementation that allows a client to
>>>> plug in an optional package registry (the default being the shared
>>>> registry). No more pluses than that. :-)
>>>>
>>>> HTH,
>>>>
>>>> Christian
>>>
>
|
|
|
Goto Forum:
Current Time: Fri Oct 31 04:18:29 EDT 2025
Powered by FUDForum. Page generated in 0.13619 seconds |
Home