EcoreEnvironment to configure arbitrary EPackage.Registry

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 109469 | | Status | CLOSED FIXED | | Importance | P2 enhancement | | Reported | Sep 14, 2005 01:23 EDT | | Modified | May 17, 2013 15:12 EDT | | Version | 1.0.0 | | Reporter | Eike Stepper |

Description

Here is an excerpt from the EMFT newsgroup (1st Thread!):

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

[eclipse-ocl-bot]

By Christian Vogt on Nov 07, 2005 16:23

Created attachment 29481 patch for org.eclipse.emf.ocl

:notepad_spiral: 2005-11-07_org.eclipse.emf.ocl.txt

[eclipse-ocl-bot]

By Christian Vogt on Nov 07, 2005 16:24

Created attachment 29482 patch for org.eclipse.emf.ocl.tests

:notepad_spiral: 2005-11-07_org.eclipse.emf.ocl.tests.txt

[eclipse-ocl-bot]

By Christian Vogt on Nov 07, 2005 16:31

EcoreEnvironmentFactory and EcoreEnvironment both have new constructors \ accepting an EPackage.Registry as a parameter.

If no registry is specified then the global registry is used as previously done.

[eclipse-ocl-bot]

By Christian Damus on Nov 10, 2005 10:20

Committed the patches. Commit comment: \ Bugzilla 109469 emft_head cvogt 0511110 EcoreEnvironment to configure arbitrary \ EPackage.Registry

[eclipse-ocl-bot]

By Christian Vogt on Nov 10, 2005 10:37

resolved - fixed

[eclipse-ocl-bot]

By Nick Boldt on Jan 28, 2008 16:34

Move to verified as per bug 206558.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2011 02:38

Closing after over a year in verified state.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2011 02:41

Closing after over a year in verified state.