Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Unregistering OclInEcore in lieu of CompleteOCL at runtime?
Unregistering OclInEcore in lieu of CompleteOCL at runtime? [message #1693112] Tue, 21 April 2015 19:45 Go to next message
Matt Eby is currently offline Matt EbyFriend
Messages: 3
Registered: February 2013
Junior Member
I have a need to maintian the same set of OCL in both OclInEcore and CompleteOCL format. The short story is that OclInEcore is used internally to a product and the CompleteOCL is used for a published standard.

I would like to be able to run regression tests against both copies of the OCL using the same set of test models and plugins. With OclInEcore the invariants and operations are registered in the generated model plugin.

What I would like to do is unregister the OclInEcore invariants and operations as part of my test setup so I can then register the CompleteOCL validators and avoid a maintaining a seperate model plugin.

I am able to unregister the invariants with:

EValidator.Registry.INSTANCE.clear();


However, the operations seem to be still causing ambiguous resolution errors:

Ambiguous resolution:
        Operation : foo::Bar.isValidIdentifier(String) : Boolean


Is there some way to unregister the operations? Or am I crazy for trying this?

[Updated on: Tue, 21 April 2015 20:57]

Report message to a moderator

Re: Unregistering OclInEcore in lieu of CompleteOCL at runtime? [message #1693167 is a reply to message #1693112] Wed, 22 April 2015 08:27 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Unregistering interpreted OCLinEcore should just be a matter of losing
the OCL delegate registrations.

Unregistering code generated OCLinEcore is a bit like saying you want to
remove some methods from java.lang.String. If you don't want them you
shouldn't put them there.

At the Abstract Syntax level OCLinEcore and Complete OCL share the same
metamodel. The tooling for the Java implementation merges Pivot.ocl with
Pivot.ecore that was derived from a number of UML models.

So perhaps your best option is to maintain only the Complete OCL copy
and to merge it into the Ecore model when you want the merge.

org.eclipse.ocl.examples.build.utilities.ConstraintMerger and its MWE2
invocations may give you some ideas.

Alternatively
org.eclipse.ocl.xtext.completeocl.as2cs.CompleteOCLSplitter can split
off the Complete OCL from a combined model.

Regards

Ed Willink




On 21/04/2015 20:45, Matt Eby wrote:
> I have a need to maintian the same set of OCL in both OclInEcore and
> CompleteOCL format. The short story is that OclInEcore is used
> internally to a product and the CompleteOCL is used for a published
> standard.
>
> I would like to be able to run regression tests against both copies of
> the OCL using the same set of test models and plugins. With OclInEcore
> the invariants and operations are registered in the generated model
> plugin.
>
> What I would like to do is unregister the OclInEcore invariants and
> operations as part of my test setup so I can then register the
> CompleteOCL validators and avoid a maintaining a seperate model plugin.
>
> I am able to unregister the invariants with:
> EValidator.Registry.INSTANCE.clear();
>
> However, the operations seem to be still causing conflicts causing
> ambiguous resolution errors:
>
> Ambiguous resolution:
> Operation : foo::Bar.isValidIdentifier(String) : Boolean
>
> Is there someway to unregister the operations? Or am I crazy for
> trying this?
>
>
>
>
Re: Unregistering OclInEcore in lieu of CompleteOCL at runtime? [message #1694184 is a reply to message #1693167] Fri, 01 May 2015 16:47 Go to previous message
Matt Eby is currently offline Matt EbyFriend
Messages: 3
Registered: February 2013
Junior Member
Hi Ed,

Thanks for the help. It got me started in the right direction.

I wanted to follow up with my solution in case others are trying to do similar things...

My main concern was not having to manage 2 separate model plugins. I'm now dynamically loading and registering the metamodel from file instead of via a generated plugin. I have 2 copies of the metamodel... one with the OclInEcore and one without. I like the idea of maintaining only one copy and using a merge when needed... but just haven't had the time to investigate that yet.

Here's the code to dynamically register a metamodel from file:

		ResourceSet metaResourceSet = new ResourceSetImpl();
		metaResourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap()
				.put("ecore", new EcoreResourceFactoryImpl());

		URI uri = URI
				.createFileURI("mymetamodel.ecore");
		Resource metaResource = metaResourceSet.getResource(uri, true);
		TreeIterator<EObject> metamodelContents = metamodelResource
				.getAllContents();

		while (metamodelContents.hasNext()) {
			EObject eObject = metamodelContents.next();
			if (eObject instanceof EPackage) {
				EPackage pkg = (EPackage) eObject;
				registry.put(pkg.getNsURI(), pkg);
			}
		}
Previous Topic:Probable move to Java 7 classes for Eclipse OCL in Mars
Next Topic:Handy API to execute OCL expressions from java code
Goto Forum:
  


Current Time: Fri Apr 26 16:12:57 GMT 2024

Powered by FUDForum. Page generated in 0.03250 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top