Home » Modeling » OCL » [Luna] Package not registered in standalone
| [Luna] Package not registered in standalone [message #1446999] |
Fri, 17 October 2014 16:34  |
 Matthias Schoettle
Messages: 21
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  |
Ed Willink
Messages: 7655
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 |
Matthias Schoettle
Messages: 21
Registered: July 2009 |
Junior Member |
|
|
Hi Ed,
thank you for your response.
Ed Willink wrote on Sat, 18 October 2014 11:12Package/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 |
Ed Willink
Messages: 7655
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
>
|
|
| | | | |
Goto Forum:
Current Time: Thu Apr 25 15:37:35 GMT 2024
Powered by FUDForum. Page generated in 0.03961 seconds |
] 
Search
Help
Register
Login
Home
