Home » Modeling » OCL » Namespace URIs and Serialization issue
| Namespace URIs and Serialization issue [message #47676] |
Thu, 10 January 2008 12:01  |
 Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Hi!
I have defined an Ecore wrapper for OCLExpression, being a simple EClass
with a reference to OCLExpression metaclass of OCLEcore.ecore.
Okay, but at the time of serialization, why XMI contains the URI
"http://www.eclipse.org/ocl/1.1.0/OCL#//ecore/OCLExpression", since the
OCLExpression i'm using belongs to OCLEcore.ecore metamodel?
The XMI looks like this:
....
<eStructuralFeatures xsi:type="ecore:EReference" name="oclExpression">
<eType xsi:type="ecore:EClass"
href="http://www.eclipse.org/ocl/1.1.0/OCL#//ecore/OCLExpression"/>
</eStructuralFeatures>
....
I had the necessity to change that URI because it was making my editors
crash (the URI wasn't registered into my EMF metamodel registry) so
I changed it in the XMI directly, writting the following existing URI:
http://www.eclipse.org/ocl/1.1.0/Ecore#//ecore/OCLExpression
I was thinking the right URI should be
http://www.eclipse.org/ocl/1.1.0/Ecore#//OCLExpression
but didn't work. The previous one did work, but then, when I change
the model in the editor and save, the URI just turns back again to:
http://www.eclipse.org/ocl/1.1.0/OCL#//ecore/OCLExpression
without permission. Any clue?
I raised a bug related with my editor crashing, pending to know
if there exist such bug.
Thanks!
Víctor Roldán.
|
|
|
| Re: Namespace URIs and Serialization issue [message #47738 is a reply to message #47676] |
Thu, 10 January 2008 14:10  |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Victor,
I wonder whether the fix for the bug that you raised about the NS URI value:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=214878
would address this problem? As far as I know, a nested EPackage has its own
namespace URI, which should be used instead of referencing it via a parent
package.
Please raise a bug for this problem and include a reproducible test case
(JUnit format would be most appreciated). Whether the problem is related
to 214878 or not, we need to fix this.
Thanks,
Christian
Víctor Roldán Betancort wrote:
> Hi!
>
> I have defined an Ecore wrapper for OCLExpression, being a simple EClass
> with a reference to OCLExpression metaclass of OCLEcore.ecore.
>
> Okay, but at the time of serialization, why XMI contains the URI
> "http://www.eclipse.org/ocl/1.1.0/OCL#//ecore/OCLExpression", since the
> OCLExpression i'm using belongs to OCLEcore.ecore metamodel?
>
> The XMI looks like this:
>
> ...
> <eStructuralFeatures xsi:type="ecore:EReference" name="oclExpression">
> <eType xsi:type="ecore:EClass"
> href="http://www.eclipse.org/ocl/1.1.0/OCL#//ecore/OCLExpression"/>
> </eStructuralFeatures>
> ...
>
> I had the necessity to change that URI because it was making my editors
> crash (the URI wasn't registered into my EMF metamodel registry) so
> I changed it in the XMI directly, writting the following existing URI:
>
>
> http://www.eclipse.org/ocl/1.1.0/Ecore#//ecore/OCLExpression
>
> I was thinking the right URI should be
> http://www.eclipse.org/ocl/1.1.0/Ecore#//OCLExpression
> but didn't work. The previous one did work, but then, when I change
> the model in the editor and save, the URI just turns back again to:
>
> http://www.eclipse.org/ocl/1.1.0/OCL#//ecore/OCLExpression
>
> without permission. Any clue?
>
> I raised a bug related with my editor crashing, pending to know
> if there exist such bug.
>
> Thanks!
>
> Víctor Roldán.
|
|
|
| Re: Namespace URIs and Serialization issue [message #47768 is a reply to message #47738] |
Thu, 10 January 2008 14:44 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Hi, Christian
I was testing my code, and my editors keep crashing, even with the
change I proposed, so I'm afraid is not related with the bug I raised.
And I think it's a bit difficult to me to reproduce it through JUnit
(haven't used it with EMF).
As you say, nested packages URIs should be used instead of parent
package. However, I suspect it's legal, but I don't know the reason to
this change during serialization.
This situation wasn't happening until I changed from 1.2.0 M3 to M4
(latest integration build).
My question is, why is it necessary to do that namespace "enforce" in
ExpressionsPackageImpl? The code looks like this:
OCLPackageImpl oclPackage = new OCLPackageImpl();
oclPackage.setName("ocl"); //$NON-NLS-1$
oclPackage.setNsPrefix("ocl"); //$NON-NLS-1$
oclPackage.setNsURI("http://www.eclipse.org/ocl/1.1.0/OCL");
oclPackage.createResource(oclPackage.getNsURI());
OCL_ROOT_PACKAGE = oclPackage;
EPackage.Registry.INSTANCE.put(OCL_ROOT_PACKAGE.getNsURI(),
OCL_ROOT_PACKAGE);
I'm not an MDT-OCL project expert, but the commentary of that part of
the code made me suspect:
/**
* Root package of the OCL Ecore model, which we have to "fake out"
* because EMF will not generate it.
*/
I don't know if that's related with this behaviour.
I'll try to reproduce it again starting from scratch and let you know.
Christian W. Damus escribió:
> Hi, Victor,
>
> I wonder whether the fix for the bug that you raised about the NS URI value:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=214878
>
> would address this problem? As far as I know, a nested EPackage has its own
> namespace URI, which should be used instead of referencing it via a parent
> package.
>
> Please raise a bug for this problem and include a reproducible test case
> (JUnit format would be most appreciated). Whether the problem is related
> to 214878 or not, we need to fix this.
>
> Thanks,
>
> Christian
>
>
> Víctor Roldán Betancort wrote:
>
>> Hi!
>>
>> I have defined an Ecore wrapper for OCLExpression, being a simple EClass
>> with a reference to OCLExpression metaclass of OCLEcore.ecore.
>>
>> Okay, but at the time of serialization, why XMI contains the URI
>> "http://www.eclipse.org/ocl/1.1.0/OCL#//ecore/OCLExpression", since the
>> OCLExpression i'm using belongs to OCLEcore.ecore metamodel?
>>
>> The XMI looks like this:
>>
>> ...
>> <eStructuralFeatures xsi:type="ecore:EReference" name="oclExpression">
>> <eType xsi:type="ecore:EClass"
>> href="http://www.eclipse.org/ocl/1.1.0/OCL#//ecore/OCLExpression"/>
>> </eStructuralFeatures>
>> ...
>>
>> I had the necessity to change that URI because it was making my editors
>> crash (the URI wasn't registered into my EMF metamodel registry) so
>> I changed it in the XMI directly, writting the following existing URI:
>>
>>
>> http://www.eclipse.org/ocl/1.1.0/Ecore#//ecore/OCLExpression
>>
>> I was thinking the right URI should be
>> http://www.eclipse.org/ocl/1.1.0/Ecore#//OCLExpression
>> but didn't work. The previous one did work, but then, when I change
>> the model in the editor and save, the URI just turns back again to:
>>
>> http://www.eclipse.org/ocl/1.1.0/OCL#//ecore/OCLExpression
>>
>> without permission. Any clue?
>>
>> I raised a bug related with my editor crashing, pending to know
>> if there exist such bug.
>>
>> Thanks!
>>
>> Víctor Roldán.
>
|
|
|
| Re: Namespace URIs and Serialization issue [message #47793 is a reply to message #47738] |
Thu, 10 January 2008 15:09 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Hi, Again Christian
I got to reproduce the bug in a clean Eclipse. I used:
eclipse-SDK-3.4M4-win32
emf-sdo-xsd-SDK-2.4.0M4
mdt-ocl-SDK-I200801031555
I made a new empty project and created a new Ecore Model.
My EReference got its URI changed again. The Ecore editor crashed as
well due to the changed-without-permision URI.
(Changed from http://www.eclipse.org/ocl/1.1.0/Ecore#//ecore/OCLExpression
to http://www.eclipse.org/OCL/1.1.0/OCL#//ecore/OCLExpression)
I don't have much experience in the EMF API, so making a JUnit to
reproduce it would take me much time. I would appreciate some advice, or
if you wish I could make a deep step-by-step guide (is not that long).
Regards,
Víctor.
Christian W. Damus escribió:
> Hi, Victor,
>
> I wonder whether the fix for the bug that you raised about the NS URI value:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=214878
>
> would address this problem? As far as I know, a nested EPackage has its own
> namespace URI, which should be used instead of referencing it via a parent
> package.
>
> Please raise a bug for this problem and include a reproducible test case
> (JUnit format would be most appreciated). Whether the problem is related
> to 214878 or not, we need to fix this.
>
> Thanks,
>
> Christian
>
>
> Víctor Roldán Betancort wrote:
>
>> Hi!
>>
>> I have defined an Ecore wrapper for OCLExpression, being a simple EClass
>> with a reference to OCLExpression metaclass of OCLEcore.ecore.
>>
>> Okay, but at the time of serialization, why XMI contains the URI
>> "http://www.eclipse.org/ocl/1.1.0/OCL#//ecore/OCLExpression", since the
>> OCLExpression i'm using belongs to OCLEcore.ecore metamodel?
>>
>> The XMI looks like this:
>>
>> ...
>> <eStructuralFeatures xsi:type="ecore:EReference" name="oclExpression">
>> <eType xsi:type="ecore:EClass"
>> href="http://www.eclipse.org/ocl/1.1.0/OCL#//ecore/OCLExpression"/>
>> </eStructuralFeatures>
>> ...
>>
>> I had the necessity to change that URI because it was making my editors
>> crash (the URI wasn't registered into my EMF metamodel registry) so
>> I changed it in the XMI directly, writting the following existing URI:
>>
>>
>> http://www.eclipse.org/ocl/1.1.0/Ecore#//ecore/OCLExpression
>>
>> I was thinking the right URI should be
>> http://www.eclipse.org/ocl/1.1.0/Ecore#//OCLExpression
>> but didn't work. The previous one did work, but then, when I change
>> the model in the editor and save, the URI just turns back again to:
>>
>> http://www.eclipse.org/ocl/1.1.0/OCL#//ecore/OCLExpression
>>
>> without permission. Any clue?
>>
>> I raised a bug related with my editor crashing, pending to know
>> if there exist such bug.
>>
>> Thanks!
>>
>> Víctor Roldán.
>
|
|
|
| Re: Namespace URIs and Serialization issue [message #47823 is a reply to message #47768] |
Thu, 10 January 2008 15:11 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Victor,
No need to bother. I have a JUnit that reproduces the problem, and I am
fixing it.
More comments in-line, below.
Cheers,
Christian
Víctor Roldán Betancort wrote:
> Hi, Christian
>
> I was testing my code, and my editors keep crashing, even with the
> change I proposed, so I'm afraid is not related with the bug I raised.
> And I think it's a bit difficult to me to reproduce it through JUnit
> (haven't used it with EMF).
>
> As you say, nested packages URIs should be used instead of parent
> package. However, I suspect it's legal, but I don't know the reason to
> this change during serialization.
This URI actually works because, at run-time, the Ecore binding package is
added as a child to the root OCL package, so resolving the URI works
despite the fact that it should traverse a cross-resource containment
reference.
> This situation wasn't happening until I changed from 1.2.0 M3 to M4
> (latest integration build).
That's interesting. I'm not sure what would have changed in the order of
package initialization to cause this.
> My question is, why is it necessary to do that namespace "enforce" in
> ExpressionsPackageImpl? The code looks like this:
>
>
> OCLPackageImpl oclPackage = new OCLPackageImpl();
> oclPackage.setName("ocl"); //$NON-NLS-1$
> oclPackage.setNsPrefix("ocl"); //$NON-NLS-1$
> oclPackage.setNsURI("http://www.eclipse.org/ocl/1.1.0/OCL");
> oclPackage.createResource(oclPackage.getNsURI());
>
> OCL_ROOT_PACKAGE = oclPackage;
> EPackage.Registry.INSTANCE.put(OCL_ROOT_PACKAGE.getNsURI(),
> OCL_ROOT_PACKAGE);
>
> I'm not an MDT-OCL project expert, but the commentary of that part of
> the code made me suspect:
>
> /**
> * Root package of the OCL Ecore model, which we have to "fake out"
> * because EMF will not generate it.
> */
There is an open enhancement request on EMF to allow generation of EPackages
that have no EClassifiers of their own, to support grouping of sub-packages
in an otherwise empty parent package.
MDT OCL's EPackage structure is like this:
OCL
- Expressions
- Types
- Utilities
- Ecore
- UML
The OCL package doesn't have any EClassifiers, but the others all do.
Because it has no EClassifiers, the initialization of these packages is
customized to create it and register it programmatically.
> I don't know if that's related with this behaviour.
It is. The problem is, that one of the last steps in package initialization
is to create the package's resource. It is this resource's URI (which is
the package NS URI) that determines the HREF that you see in the XMI.
Because MDT OCL is adding sub-packages to the OCL package before completing
their initialization, none of them actually gets its own resource. They
are all added to the resource created by the OCL package.
> I'll try to reproduce it again starting from scratch and let you know.
No need. I already have created a JUnit test for this.
> Christian W. Damus escribió:
>> Hi, Victor,
>>
>> I wonder whether the fix for the bug that you raised about the NS URI
>> value:
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=214878
>>
>> would address this problem? As far as I know, a nested EPackage has its
>> own namespace URI, which should be used instead of referencing it via a
>> parent package.
>>
>> Please raise a bug for this problem and include a reproducible test case
>> (JUnit format would be most appreciated). Whether the problem is related
>> to 214878 or not, we need to fix this.
>>
>> Thanks,
>>
>> Christian
>>
>>
-----8<-----
|
|
|
Goto Forum:
Current Time: Wed Apr 24 13:51:35 GMT 2024
Powered by FUDForum. Page generated in 0.03159 seconds |
] 
Search
Help
Register
Login
Home
