Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » [Luna] Package not registered in standalone
[Luna] Package not registered in standalone [message #1446999] Fri, 17 October 2014 16:34 Go to next message
Matthias Schoettle is currently offline Matthias SchoettleFriend
Messages: 20
Registered: July 2009
Junior Member
Hello,

we are using OCL in a standalone application and some constraints are not evaluated anymore (more specifically, are always evaluated to true) after switching from Kepler (SR2) to Luna (SR1), i.e., using the same code they are properly evaluated using Kepler, but not Luna.

Our project uses a CompleteOCL .ocl file for the constraints. Also, we have some OCLinEcore inside our .ecore model, where derived attributes are defined using OCL. Even though it is a standalone application, all our projects are plugin projects (hopefully this doesn't cause this problem). In the .ocl file we import our ecore model using platform:/plugin/<pluginID>/model/X.ecore. Importing by nsURI makes it work, but then during development time it cannot be found since it is not loaded/registered.

Here is what I found out through debugging the checking of the particular constraint inside OCL:

The main reason why the constraint is evaluated to true is, because the EStructuralFeature for the derived attribute/reference is searched for, it is not found (even though it's there), and hence an exception is thrown. The EStructuralFeature is the correct one, but the corresponding implementation in EClass.getFeatureID(EStructuralFeature) makes sure it is the same instance.

This is when I realized that the EStructuralFeature is from our generated EMF package, but the EClass instance where it is searched for is from a dynamic EPackage for our package.

I then found out that our generated package is not found when processing the import statements of the .ocl file and hence, this dynamic instance is initialized. I tracked this down to StandaloneProjectMap where initializePackageRegistry(ResourceSet) is done differently (I think this is related to bug #410518. As far as I can see the packages are actually not registered to the package registry anymore.

So in the end, there are two major differences in the package registry that can be obtained from StandaloneProjectMap.getPackageRegistry(ResourceSet). One, the entries of the registry map differently, for example:
http://www.eclipse.org/emf/2002/Ecore=http://www.eclipse.org/emf/2002/Ecore with LoadFirstStrategy (Luna)

vs

platform:/resource/org.eclipse.emf.ecore/model/Ecore.ecore=http://www.eclipse.org/emf/2002/Ecore => org.eclipse.emf.ecore.EcorePackage, model/Ecore.genmodel, model/Ecore.ecore#/ (Kepler)


Second, but I don't think its related to this problem, is that there are less packages registered in total when running on Luna compared to Kepler.

Could there be a problem on our side or is this a bug?

Thanks,
Matthias
Re: [Luna] Package not registered in standalone [message #1447589 is a reply to message #1446999] Sat, 18 October 2014 15:12 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5534
Registered: July 2009
Senior Member
Hi

Package/model registrations can be a bit of a nightmare. Most EMF tools
allow diverse URI references to lead to confusion and metamodel
schizophrenia. The ProjectMap endeavours to share competing models thus
the "LoadFirstStrategy" uses whichever is first referenced for all
subsequent equivalent references.

Prior to Luna it was assumed that each genmodel registration was to a
distinct URI. But SysML has at least 5 URIs for a single genmodel so a
significant revision was required that reduced the over-eager loading of
some packages.

... might be your problem might be a ProjectMap problem ..

Whichever some custom configuration should make the problem go away.

There are a few tracing options in StandaloneProjectMap, you may find
that setting some of them gives you some insight.

EMF often treats platform:/resource and platform:/plugin as the same.
You might find that platform:/resource works better.

Using nsURIs should work at development time provided you have a
generated package registration that associates the nsURI with a genmodel.

Regards

Ed Willink


On 17/10/2014 17:34, Matthias Schoettle wrote:
> Hello,
>
> we are using OCL in a standalone application and some constraints are
> not evaluated anymore (more specifically, are always evaluated to true)
> after switching from Kepler (SR2) to Luna (SR1), i.e., using the same
> code they are properly evaluated using Kepler, but not Luna.
>
> Our project uses a CompleteOCL .ocl file for the constraints. Also, we
> have some OCLinEcore inside our .ecore model, where derived attributes
> are defined using OCL. Even though it is a standalone application, all
> our projects are plugin projects (hopefully this doesn't cause this
> problem). In the .ocl file we import our ecore model using
> platform:/plugin/<pluginID>/model/X.ecore. Importing by nsURI makes it
> work, but then during development time it cannot be found since it is
> not loaded/registered.
>
> Here is what I found out through debugging the checking of the
> particular constraint inside OCL:
>
> The main reason why the constraint is evaluated to true is, because the
> EStructuralFeature for the derived attribute/reference is searched for,
> it is not found (even though it's there), and hence an exception is
> thrown. The EStructuralFeature is the correct one, but the corresponding
> implementation in EClass.getFeatureID(EStructuralFeature) makes sure it
> is the same instance.
>
> This is when I realized that the EStructuralFeature is from our
> generated EMF package, but the EClass instance where it is searched for
> is from a dynamic EPackage for our package.
>
> I then found out that our generated package is not found when processing
> the import statements of the .ocl file and hence, this dynamic instance
> is initialized. I tracked this down to StandaloneProjectMap where
> initializePackageRegistry(ResourceSet) is done differently (I think this
> is related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=410518. As
> far as I can see the packages are actually not registered to the package
> registry anymore.
>
> So in the end, there are two major differences in the package registry
> that can be obtained from
> StandaloneProjectMap.getPackageRegistry(ResourceSet). One, the entries
> of the registry map differently, for example:
> http://www.eclipse.org/emf/2002/Ecore=http://www.eclipse.org/emf/2002/Ecore
> with LoadFirstStrategy (Luna)
>
> vs
>
> platform:/resource/org.eclipse.emf.ecore/model/Ecore.ecore=http://www.eclipse.org/emf/2002/Ecore
> => org.eclipse.emf.ecore.EcorePackage, model/Ecore.genmodel,
> model/Ecore.ecore#/ (Kepler)
>
>
> Second, but I don't think its related to this problem, is that there are
> less packages registered in total when running on Luna compared to Kepler.
>
> Could there be a problem on our side or is this a bug?
>
> Thanks,
> Matthias
Re: [Luna] Package not registered in standalone [message #1450729 is a reply to message #1447589] Wed, 22 October 2014 21:21 Go to previous messageGo to next message
Matthias Schoettle is currently offline Matthias SchoettleFriend
Messages: 20
Registered: July 2009
Junior Member
Hi Ed,

thank you for your response.

Ed Willink wrote on Sat, 18 October 2014 11:12
Package/model registrations can be a bit of a nightmare. Most EMF tools
allow diverse URI references to lead to confusion and metamodel
schizophrenia. The ProjectMap endeavours to share competing models thus
the "LoadFirstStrategy" uses whichever is first referenced for all
subsequent equivalent references.


I see. From what I see, though, the reference to the .ecore (neither with platform:/resource nor platform:/plugin) is not considered equivalent to the nsURI, because it is never registered as such (as opposed to the previous version).

Ed Willink wrote on Sat, 18 October 2014 11:12

Whichever some custom configuration should make the problem go away.


What does work indeed is if I add a custom mapping from the .ecore models using platform:/plugin and platform:/resource URIs to the package registry instance that is passed to OCL.newInstance(...).

Then, when it does not find a package for the nsURI in the package registry, it will delegate it to the delegate package registry where this mapping is contained.

Ed Willink wrote on Sat, 18 October 2014 11:12

There are a few tracing options in StandaloneProjectMap, you may find
that setting some of them gives you some insight.


It seems to not work when running in a standalone application, because the platform is not started and so no debug service tracker is initialized.

Ed Willink wrote on Sat, 18 October 2014 11:12

Using nsURIs should work at development time provided you have a
generated package registration that associates the nsURI with a genmodel.


That would of course be best, because it would also solve this problem. However, it doesn't work for me. The model plugin project has a generated package registration (org.eclipse.emf.ecore.generated_package), the OCL file is contained in another project. I tried putting it into the same as the ecore model, but that didn't help.

Regards,
Matthias
Re: [Luna] Package not registered in standalone [message #1451066 is a reply to message #1450729] Thu, 23 October 2014 09:22 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5534
Registered: July 2009
Senior Member
Hi

I obviously cannot comment further. It can work. I cannot tell which of
many typo opportunities you have taken or what bug you may have run into.

Regards

Ed Willink


On 22/10/2014 22:21, Matthias Schoettle wrote:
> Hi Ed,
>
> thank you for your response.
>
> Ed Willink wrote on Sat, 18 October 2014 11:12
>> Package/model registrations can be a bit of a nightmare. Most EMF
>> tools allow diverse URI references to lead to confusion and metamodel
>> schizophrenia. The ProjectMap endeavours to share competing models
>> thus the "LoadFirstStrategy" uses whichever is first referenced for
>> all subsequent equivalent references.
>
>
> I see. From what I see, though, the reference to the .ecore (neither
> with platform:/resource nor platform:/plugin) is not considered
> equivalent to the nsURI, because it is never registered as such (as
> opposed to the previous version).
>
> Ed Willink wrote on Sat, 18 October 2014 11:12
>> Whichever some custom configuration should make the problem go away.
>
>
> What does work indeed is if I add a custom mapping from the .ecore
> models using platform:/plugin and platform:/resource URIs to the package
> registry instance that is passed to OCL.newInstance(...).
>
> Then, when it does not find a package for the nsURI in the package
> registry, it will delegate it to the delegate package registry where
> this mapping is contained.
>
> Ed Willink wrote on Sat, 18 October 2014 11:12
>> There are a few tracing options in StandaloneProjectMap, you may find
>> that setting some of them gives you some insight.
>
>
> It seems to not work when running in a standalone application, because
> the platform is not started and so no debug service tracker is initialized.
>
> Ed Willink wrote on Sat, 18 October 2014 11:12
>> Using nsURIs should work at development time provided you have a
>> generated package registration that associates the nsURI with a genmodel.
>
>
> That would of course be best, because it would also solve this problem.
> However, it doesn't work for me. The model plugin project has a
> generated package registration
> (org.eclipse.emf.ecore.generated_package), the OCL file is contained in
> another project. I tried putting it into the same as the ecore model,
> but that didn't help.
>
> Regards,
> Matthias
>
Re: [Luna] Package not registered in standalone [message #1451364 is a reply to message #1446999] Thu, 23 October 2014 18:23 Go to previous messageGo to next message
Matthias Schoettle is currently offline Matthias SchoettleFriend
Messages: 20
Registered: July 2009
Junior Member
Of course. Here is an example project. I created the Complete OCL file using the wizard and selected "Browse Target Platform Packages...", where the nsURI of my Ecore model showed up. However, the import used the file path (e.g., "Test.ecore" if its in the same directory or "/resource/..." if its in a different project).

I changed the import to the nsURI of my Ecore model, closed it, opened it again and then the error about the unresolved import appeared.

Best regards,
Matthias
Re: [Luna] Package not registered in standalone [message #1451699 is a reply to message #1451364] Fri, 24 October 2014 06:54 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5534
Registered: July 2009
Senior Member
Hi

Your example is invalid; no .project file.

Your discussion seems to have nothing to do with standalone, so even if
I fixed up the .project I wouldn't know what you're real problem is.

Regards


Ed Willink


On 23/10/2014 19:23, Matthias Schoettle wrote:
> Of course. Here is an example project. I created the Complete OCL file using the wizard and selected "Browse Target Platform Packages...", where the nsURI of my Ecore model showed up. However, the import used the file path (e.g., "Test.ecore" if its in the same directory or "/resource/..." if its in a different project).
>
> I changed the import to the nsURI of my Ecore model, closed it, opened it again and then the error about the unresolved import appeared.
>
> Best regards,
> Matthias
>
Re: [Luna] Package not registered in standalone [message #1452128 is a reply to message #1451699] Fri, 24 October 2014 21:02 Go to previous messageGo to next message
Matthias Schoettle is currently offline Matthias SchoettleFriend
Messages: 20
Registered: July 2009
Junior Member
I wasn't exactly sure, which of my comments you answered to. My response with the example project was regarding your comment that it should work to import a model using the nsURI at development time. Attached is the full project archive.

I added a small class (OCLTest in the .example package) that, when using the nsURI to import the model, evaluates to true, and when changing it to an import using platform:/resource evaluates to false.

Regards,
Matthias

Re: [Luna] Package not registered in standalone [message #1452424 is a reply to message #1452128] Sat, 25 October 2014 08:49 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5534
Registered: July 2009
Senior Member
Hi

It is not obvious where "using the nsURI to import the model" is and so
"changing it to an import using platform:/resource" is hard. Out of the
box, the example evaluates to false for me rather than true as you suggest.

Try studying: https://wiki.eclipse.org/OCL/ForumNetiquette

Always better to formulate as a JUnit test so that expectations are in
code rather than flummery.

Regards

Ed Willink

On 24/10/2014 22:02, Matthias Schoettle wrote:
> I wasn't exactly sure, which of my comments you answered to. My response with the example project was regarding your comment that it should work to import a model using the nsURI at development time. Attached is the full project archive.
>
> I added a small class (OCLTest in the .example package) that, when using the nsURI to import the model, evaluates to true, and when changing it to an import using platform:/resource evaluates to false.
>
> Regards,
> Matthias
>
>
Previous Topic:OCL query failing for the 'matches' function of String
Next Topic:Luna Problem with derived properties
Goto Forum:
  


Current Time: Sun Dec 17 21:39:35 GMT 2017

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

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