Home » Modeling » EMF » URI of Classifiers in subpackages
| URI of Classifiers in subpackages [message #430799] |
Wed, 10 June 2009 19:15  |
 Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Hi,
I've searched the FAQ for this one, but have not had any success.
Given an EPackage with a number of classifiers and subpackages which may
or may not contain other classifiers, is there a way to compute the URI
(-fragment) that will resolve to a specific classifier when the model
code will be generated by the Ecore generator?
Example:
EPackage P1 - nsURI: http://a, classifiers C1, C2
Subpackage P2 - nsURI: http://b, no classifiers
Subsubpackage P3 - nsURI: http://c, classifier C3
I've tried to get a reference to C3 with
http://c#//C3
or
http://a#//P2/P3/C3.
Both attempts were not successfull. It turns out, that
EcoreUtil.getURI(Subsubpackage.Literals.C3) returns http://a#//P3/C3.
Digging through the code of the generator reveals that empty packages
will not be generated. This leads to the given, modified containment
hierarchy, that will produce the unexpected (at least by me) URI.
The question is:
How can I predict the URI of a generated EClass with respect to nested
packages, cross resource containment and all other fancy optimizations
that may happen in the Ecore generator?
Thanks,
Sebastian
|
|
|
| Re: URI of Classifiers in subpackages [message #430801 is a reply to message #430799] |
Wed, 10 June 2009 19:57  |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Sebastian,
Comments below.
Sebastian Zarnekow wrote:
> Hi,
>
> I've searched the FAQ for this one, but have not had any success.
>
> Given an EPackage with a number of classifiers and subpackages
Oh joy. I'm not sure why people are so enamored with subpackages, given
they provide no substantial value and and yet tend to cause problems...
> which may or may not contain other classifiers, is there a way to
> compute the URI (-fragment) that will resolve to a specific classifier
> when the model code will be generated by the Ecore generator?
You're aware of https://bugs.eclipse.org/bugs/show_bug.cgi?id=142856 I
guess? If you really want a package to be generated, put in a dummy
EDataType as a workaround.
>
> Example:
>
> EPackage P1 - nsURI: http://a, classifiers C1, C2
> Subpackage P2 - nsURI: http://b, no classifiers
> Subsubpackage P3 - nsURI: http://c, classifier C3
Why do you care to have this nesting? Why not just have separate
packages who's qualified names happen to induce this tree?
>
> I've tried to get a reference to C3 with
> http://c#//C3
> or
> http://a#//P2/P3/C3.
> Both attempts were not successfull. It turns out, that
> EcoreUtil.getURI(Subsubpackage.Literals.C3) returns http://a#//P3/C3.
I expect http://c#//C3 to resolve though but maybe I'm assuming changes
made in 2.5 (to create a resource for subpackages). Which version of EMF
are you using?
> Digging through the code of the generator reveals that empty packages
> will not be generated. This leads to the given, modified containment
> hierarchy, that will produce the unexpected (at least by me) URI.
>
> The question is:
> How can I predict the URI of a generated EClass with respect to nested
> packages, cross resource containment and all other fancy optimizations
> that may happen in the Ecore generator?
Add a dummy classifier, and it's more predictable.
>
> Thanks,
> Sebastian
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: URI of Classifiers in subpackages [message #430802 is a reply to message #430801] |
Wed, 10 June 2009 20:12 |
Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
I'm trying to fix a bug in Xtext, that occures in the rare case of empty
subpackages. I have not any influence on the structure of the metamodel,
nor do I like the idea of subpackages at all...
http://c#/c3 did not resolve for me, but I'll try again. Xtext requires
EMF 2.5, so I hope this will work.
Thanks for your help,
Sebastian
Am 10.06.2009 21:57 Uhr, schrieb Ed Merks:
> Sebastian,
>
> Comments below.
>
> Sebastian Zarnekow wrote:
>> Hi,
>>
>> I've searched the FAQ for this one, but have not had any success.
>>
>> Given an EPackage with a number of classifiers and subpackages
> Oh joy. I'm not sure why people are so enamored with subpackages, given
> they provide no substantial value and and yet tend to cause problems...
>> which may or may not contain other classifiers, is there a way to
>> compute the URI (-fragment) that will resolve to a specific classifier
>> when the model code will be generated by the Ecore generator?
> You're aware of https://bugs.eclipse.org/bugs/show_bug.cgi?id=142856 I
> guess? If you really want a package to be generated, put in a dummy
> EDataType as a workaround.
>>
>> Example:
>>
>> EPackage P1 - nsURI: http://a, classifiers C1, C2
>> Subpackage P2 - nsURI: http://b, no classifiers
>> Subsubpackage P3 - nsURI: http://c, classifier C3
> Why do you care to have this nesting? Why not just have separate
> packages who's qualified names happen to induce this tree?
>>
>> I've tried to get a reference to C3 with
>> http://c#//C3
>> or
>> http://a#//P2/P3/C3.
>> Both attempts were not successfull. It turns out, that
>> EcoreUtil.getURI(Subsubpackage.Literals.C3) returns http://a#//P3/C3.
> I expect http://c#//C3 to resolve though but maybe I'm assuming changes
> made in 2.5 (to create a resource for subpackages). Which version of EMF
> are you using?
>> Digging through the code of the generator reveals that empty packages
>> will not be generated. This leads to the given, modified containment
>> hierarchy, that will produce the unexpected (at least by me) URI.
>>
>> The question is:
>> How can I predict the URI of a generated EClass with respect to nested
>> packages, cross resource containment and all other fancy optimizations
>> that may happen in the Ecore generator?
> Add a dummy classifier, and it's more predictable.
>>
>> Thanks,
>> Sebastian
>>
|
|
|
| Re: URI of Classifiers in subpackages [message #430803 is a reply to message #430802] |
Wed, 10 June 2009 20:24 |
Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
I've got the following two testcases. The first one is green while the
second will fail on the last line.
I assume that I'm missing something fundamental here ...
public void testUriFormat() throws Exception {
URI uri = EcoreUtil.getURI(SubsubpackagePackage.Literals.ANOTHER_TYPE) ;
assertTrue(AmetamodelPackage.eNS_URI.equals(uri.trimFragment ().toString()));
ResourceSet set = new ResourceSetImpl();
EObject eObject = set.getEObject(uri, true);
assertSame(SubsubpackagePackage.Literals.ANOTHER_TYPE, eObject);
}
public void testUriFormat2() throws Exception {
URI uri = URI.createURI(SubsubpackagePackage.eNS_URI + "#//" +
SubsubpackagePackage.Literals.ANOTHER_TYPE.getName());
assertTrue(EPackage.Registry.INSTANCE.containsKey(Subsubpack agePackage.eNS_URI));
assertFalse(EcoreUtil.getURI(SubsubpackagePackage.Literals.A NOTHER_TYPE).equals(uri));
ResourceSet set = new ResourceSetImpl();
EObject eObject = set.getEObject(uri, true);
assertSame(SubsubpackagePackage.Literals.ANOTHER_TYPE, eObject); // fail
}
Your help is very appreciated,
Sebastian
Am 10.06.2009 22:12 Uhr, schrieb Sebastian Zarnekow:
> Hi Ed,
>
> I'm trying to fix a bug in Xtext, that occures in the rare case of empty
> subpackages. I have not any influence on the structure of the metamodel,
> nor do I like the idea of subpackages at all...
>
> http://c#/c3 did not resolve for me, but I'll try again. Xtext requires
> EMF 2.5, so I hope this will work.
>
> Thanks for your help,
> Sebastian
>
>
> Am 10.06.2009 21:57 Uhr, schrieb Ed Merks:
>> Sebastian,
>>
>> Comments below.
>>
>> Sebastian Zarnekow wrote:
>>> Hi,
>>>
>>> I've searched the FAQ for this one, but have not had any success.
>>>
>>> Given an EPackage with a number of classifiers and subpackages
>> Oh joy. I'm not sure why people are so enamored with subpackages, given
>> they provide no substantial value and and yet tend to cause problems...
>>> which may or may not contain other classifiers, is there a way to
>>> compute the URI (-fragment) that will resolve to a specific classifier
>>> when the model code will be generated by the Ecore generator?
>> You're aware of https://bugs.eclipse.org/bugs/show_bug.cgi?id=142856 I
>> guess? If you really want a package to be generated, put in a dummy
>> EDataType as a workaround.
>>>
>>> Example:
>>>
>>> EPackage P1 - nsURI: http://a, classifiers C1, C2
>>> Subpackage P2 - nsURI: http://b, no classifiers
>>> Subsubpackage P3 - nsURI: http://c, classifier C3
>> Why do you care to have this nesting? Why not just have separate
>> packages who's qualified names happen to induce this tree?
>>>
>>> I've tried to get a reference to C3 with
>>> http://c#//C3
>>> or
>>> http://a#//P2/P3/C3.
>>> Both attempts were not successfull. It turns out, that
>>> EcoreUtil.getURI(Subsubpackage.Literals.C3) returns http://a#//P3/C3.
>> I expect http://c#//C3 to resolve though but maybe I'm assuming changes
>> made in 2.5 (to create a resource for subpackages). Which version of EMF
>> are you using?
>>> Digging through the code of the generator reveals that empty packages
>>> will not be generated. This leads to the given, modified containment
>>> hierarchy, that will produce the unexpected (at least by me) URI.
>>>
>>> The question is:
>>> How can I predict the URI of a generated EClass with respect to nested
>>> packages, cross resource containment and all other fancy optimizations
>>> that may happen in the Ecore generator?
>> Add a dummy classifier, and it's more predictable.
>>>
>>> Thanks,
>>> Sebastian
>>>
>
|
|
|
| Re: URI of Classifiers in subpackages [message #430806 is a reply to message #430802] |
Wed, 10 June 2009 22:19 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Sebastian,
Did you try http://c#/c3 or http://c#//c3?
Sebastian Zarnekow wrote:
> Hi Ed,
>
> I'm trying to fix a bug in Xtext, that occures in the rare case of
> empty subpackages. I have not any influence on the structure of the
> metamodel, nor do I like the idea of subpackages at all...
>
> http://c#/c3 did not resolve for me, but I'll try again. Xtext
> requires EMF 2.5, so I hope this will work.
>
> Thanks for your help,
> Sebastian
>
>
> Am 10.06.2009 21:57 Uhr, schrieb Ed Merks:
>> Sebastian,
>>
>> Comments below.
>>
>> Sebastian Zarnekow wrote:
>>> Hi,
>>>
>>> I've searched the FAQ for this one, but have not had any success.
>>>
>>> Given an EPackage with a number of classifiers and subpackages
>> Oh joy. I'm not sure why people are so enamored with subpackages, given
>> they provide no substantial value and and yet tend to cause problems...
>>> which may or may not contain other classifiers, is there a way to
>>> compute the URI (-fragment) that will resolve to a specific classifier
>>> when the model code will be generated by the Ecore generator?
>> You're aware of https://bugs.eclipse.org/bugs/show_bug.cgi?id=142856 I
>> guess? If you really want a package to be generated, put in a dummy
>> EDataType as a workaround.
>>>
>>> Example:
>>>
>>> EPackage P1 - nsURI: http://a, classifiers C1, C2
>>> Subpackage P2 - nsURI: http://b, no classifiers
>>> Subsubpackage P3 - nsURI: http://c, classifier C3
>> Why do you care to have this nesting? Why not just have separate
>> packages who's qualified names happen to induce this tree?
>>>
>>> I've tried to get a reference to C3 with
>>> http://c#//C3
>>> or
>>> http://a#//P2/P3/C3.
>>> Both attempts were not successfull. It turns out, that
>>> EcoreUtil.getURI(Subsubpackage.Literals.C3) returns http://a#//P3/C3.
>> I expect http://c#//C3 to resolve though but maybe I'm assuming changes
>> made in 2.5 (to create a resource for subpackages). Which version of EMF
>> are you using?
>>> Digging through the code of the generator reveals that empty packages
>>> will not be generated. This leads to the given, modified containment
>>> hierarchy, that will produce the unexpected (at least by me) URI.
>>>
>>> The question is:
>>> How can I predict the URI of a generated EClass with respect to nested
>>> packages, cross resource containment and all other fancy optimizations
>>> that may happen in the Ecore generator?
>> Add a dummy classifier, and it's more predictable.
>>>
>>> Thanks,
>>> Sebastian
>>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: URI of Classifiers in subpackages [message #430808 is a reply to message #430803] |
Wed, 10 June 2009 22:21 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Sebastian,
I'll look tomorrow...
Sebastian Zarnekow wrote:
> Hi Ed,
>
> I've got the following two testcases. The first one is green while the
> second will fail on the last line.
> I assume that I'm missing something fundamental here ...
>
> public void testUriFormat() throws Exception {
> URI uri =
> EcoreUtil.getURI(SubsubpackagePackage.Literals.ANOTHER_TYPE) ;
> assertTrue(AmetamodelPackage.eNS_URI.equals(uri.trimFragment ().toString()));
>
> ResourceSet set = new ResourceSetImpl();
> EObject eObject = set.getEObject(uri, true);
> assertSame(SubsubpackagePackage.Literals.ANOTHER_TYPE, eObject);
> }
>
> public void testUriFormat2() throws Exception {
> URI uri = URI.createURI(SubsubpackagePackage.eNS_URI + "#//" +
> SubsubpackagePackage.Literals.ANOTHER_TYPE.getName());
> assertTrue(EPackage.Registry.INSTANCE.containsKey(Subsubpack agePackage.eNS_URI));
>
> assertFalse(EcoreUtil.getURI(SubsubpackagePackage.Literals.A NOTHER_TYPE).equals(uri));
>
> ResourceSet set = new ResourceSetImpl();
> EObject eObject = set.getEObject(uri, true);
> assertSame(SubsubpackagePackage.Literals.ANOTHER_TYPE, eObject);
> // fail
> }
>
> Your help is very appreciated,
> Sebastian
>
> Am 10.06.2009 22:12 Uhr, schrieb Sebastian Zarnekow:
>> Hi Ed,
>>
>> I'm trying to fix a bug in Xtext, that occures in the rare case of empty
>> subpackages. I have not any influence on the structure of the metamodel,
>> nor do I like the idea of subpackages at all...
>>
>> http://c#/c3 did not resolve for me, but I'll try again. Xtext requires
>> EMF 2.5, so I hope this will work.
>>
>> Thanks for your help,
>> Sebastian
>>
>>
>> Am 10.06.2009 21:57 Uhr, schrieb Ed Merks:
>>> Sebastian,
>>>
>>> Comments below.
>>>
>>> Sebastian Zarnekow wrote:
>>>> Hi,
>>>>
>>>> I've searched the FAQ for this one, but have not had any success.
>>>>
>>>> Given an EPackage with a number of classifiers and subpackages
>>> Oh joy. I'm not sure why people are so enamored with subpackages, given
>>> they provide no substantial value and and yet tend to cause problems...
>>>> which may or may not contain other classifiers, is there a way to
>>>> compute the URI (-fragment) that will resolve to a specific classifier
>>>> when the model code will be generated by the Ecore generator?
>>> You're aware of https://bugs.eclipse.org/bugs/show_bug.cgi?id=142856 I
>>> guess? If you really want a package to be generated, put in a dummy
>>> EDataType as a workaround.
>>>>
>>>> Example:
>>>>
>>>> EPackage P1 - nsURI: http://a, classifiers C1, C2
>>>> Subpackage P2 - nsURI: http://b, no classifiers
>>>> Subsubpackage P3 - nsURI: http://c, classifier C3
>>> Why do you care to have this nesting? Why not just have separate
>>> packages who's qualified names happen to induce this tree?
>>>>
>>>> I've tried to get a reference to C3 with
>>>> http://c#//C3
>>>> or
>>>> http://a#//P2/P3/C3.
>>>> Both attempts were not successfull. It turns out, that
>>>> EcoreUtil.getURI(Subsubpackage.Literals.C3) returns http://a#//P3/C3.
>>> I expect http://c#//C3 to resolve though but maybe I'm assuming changes
>>> made in 2.5 (to create a resource for subpackages). Which version of
>>> EMF
>>> are you using?
>>>> Digging through the code of the generator reveals that empty packages
>>>> will not be generated. This leads to the given, modified containment
>>>> hierarchy, that will produce the unexpected (at least by me) URI.
>>>>
>>>> The question is:
>>>> How can I predict the URI of a generated EClass with respect to nested
>>>> packages, cross resource containment and all other fancy optimizations
>>>> that may happen in the Ecore generator?
>>> Add a dummy classifier, and it's more predictable.
>>>>
>>>> Thanks,
>>>> Sebastian
>>>>
>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: URI of Classifiers in subpackages [message #430810 is a reply to message #430806] |
Thu, 11 June 2009 07:12 |
Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
I've added a third testcase which fails with a NumberFormatException:
public void testUriFormat3() throws Exception {
URI uri = URI.createURI(SubsubpackagePackage.eNS_URI + "#/" +
SubsubpackagePackage.Literals.ANOTHER_TYPE.getName());
assertTrue(EPackage.Registry.INSTANCE.containsKey(Subsubpack agePackage.eNS_URI));
assertFalse(EcoreUtil.getURI(SubsubpackagePackage.Literals.A NOTHER_TYPE).equals(uri));
ResourceSet set = new ResourceSetImpl();
set.getEObject(uri, true); // fail: NumberFormatException
}
- Sebastian
Am 11.06.2009 0:19 Uhr, schrieb Ed Merks:
> Sebastian,
>
> Did you try http://c#/c3 or http://c#//c3?
>
> Sebastian Zarnekow wrote:
>> Hi Ed,
>>
>> I'm trying to fix a bug in Xtext, that occures in the rare case of
>> empty subpackages. I have not any influence on the structure of the
>> metamodel, nor do I like the idea of subpackages at all...
>>
>> http://c#/c3 did not resolve for me, but I'll try again. Xtext
>> requires EMF 2.5, so I hope this will work.
>>
>> Thanks for your help,
>> Sebastian
>>
>>
>> Am 10.06.2009 21:57 Uhr, schrieb Ed Merks:
>>> Sebastian,
>>>
>>> Comments below.
>>>
>>> Sebastian Zarnekow wrote:
>>>> Hi,
>>>>
>>>> I've searched the FAQ for this one, but have not had any success.
>>>>
>>>> Given an EPackage with a number of classifiers and subpackages
>>> Oh joy. I'm not sure why people are so enamored with subpackages, given
>>> they provide no substantial value and and yet tend to cause problems...
>>>> which may or may not contain other classifiers, is there a way to
>>>> compute the URI (-fragment) that will resolve to a specific classifier
>>>> when the model code will be generated by the Ecore generator?
>>> You're aware of https://bugs.eclipse.org/bugs/show_bug.cgi?id=142856 I
>>> guess? If you really want a package to be generated, put in a dummy
>>> EDataType as a workaround.
>>>>
>>>> Example:
>>>>
>>>> EPackage P1 - nsURI: http://a, classifiers C1, C2
>>>> Subpackage P2 - nsURI: http://b, no classifiers
>>>> Subsubpackage P3 - nsURI: http://c, classifier C3
>>> Why do you care to have this nesting? Why not just have separate
>>> packages who's qualified names happen to induce this tree?
>>>>
>>>> I've tried to get a reference to C3 with
>>>> http://c#//C3
>>>> or
>>>> http://a#//P2/P3/C3.
>>>> Both attempts were not successfull. It turns out, that
>>>> EcoreUtil.getURI(Subsubpackage.Literals.C3) returns http://a#//P3/C3.
>>> I expect http://c#//C3 to resolve though but maybe I'm assuming changes
>>> made in 2.5 (to create a resource for subpackages). Which version of EMF
>>> are you using?
>>>> Digging through the code of the generator reveals that empty packages
>>>> will not be generated. This leads to the given, modified containment
>>>> hierarchy, that will produce the unexpected (at least by me) URI.
>>>>
>>>> The question is:
>>>> How can I predict the URI of a generated EClass with respect to nested
>>>> packages, cross resource containment and all other fancy optimizations
>>>> that may happen in the Ecore generator?
>>> Add a dummy classifier, and it's more predictable.
>>>>
>>>> Thanks,
>>>> Sebastian
>>>>
>>
|
|
|
| Re: URI of Classifiers in subpackages [message #430814 is a reply to message #430810] |
Thu, 11 June 2009 08:55 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Sebastian,
Yes, the first segment is interpreted directly by the resource and in
the default implementation must be a index in the
Resource.getContents(), which when absent is interpreted to be 0. I
only asked this because you showed the first form in your answer and I
wasn't sure that was a typo of what you actually did...
Sebastian Zarnekow wrote:
> Hi Ed,
>
> I've added a third testcase which fails with a NumberFormatException:
>
> public void testUriFormat3() throws Exception {
> URI uri = URI.createURI(SubsubpackagePackage.eNS_URI + "#/" +
> SubsubpackagePackage.Literals.ANOTHER_TYPE.getName());
> assertTrue(EPackage.Registry.INSTANCE.containsKey(Subsubpack agePackage.eNS_URI));
>
> assertFalse(EcoreUtil.getURI(SubsubpackagePackage.Literals.A NOTHER_TYPE).equals(uri));
>
> ResourceSet set = new ResourceSetImpl();
> set.getEObject(uri, true); // fail: NumberFormatException
> }
>
> - Sebastian
>
> Am 11.06.2009 0:19 Uhr, schrieb Ed Merks:
>> Sebastian,
>>
>> Did you try http://c#/c3 or http://c#//c3?
>>
>> Sebastian Zarnekow wrote:
>>> Hi Ed,
>>>
>>> I'm trying to fix a bug in Xtext, that occures in the rare case of
>>> empty subpackages. I have not any influence on the structure of the
>>> metamodel, nor do I like the idea of subpackages at all...
>>>
>>> http://c#/c3 did not resolve for me, but I'll try again. Xtext
>>> requires EMF 2.5, so I hope this will work.
>>>
>>> Thanks for your help,
>>> Sebastian
>>>
>>>
>>> Am 10.06.2009 21:57 Uhr, schrieb Ed Merks:
>>>> Sebastian,
>>>>
>>>> Comments below.
>>>>
>>>> Sebastian Zarnekow wrote:
>>>>> Hi,
>>>>>
>>>>> I've searched the FAQ for this one, but have not had any success.
>>>>>
>>>>> Given an EPackage with a number of classifiers and subpackages
>>>> Oh joy. I'm not sure why people are so enamored with subpackages,
>>>> given
>>>> they provide no substantial value and and yet tend to cause
>>>> problems...
>>>>> which may or may not contain other classifiers, is there a way to
>>>>> compute the URI (-fragment) that will resolve to a specific
>>>>> classifier
>>>>> when the model code will be generated by the Ecore generator?
>>>> You're aware of https://bugs.eclipse.org/bugs/show_bug.cgi?id=142856 I
>>>> guess? If you really want a package to be generated, put in a dummy
>>>> EDataType as a workaround.
>>>>>
>>>>> Example:
>>>>>
>>>>> EPackage P1 - nsURI: http://a, classifiers C1, C2
>>>>> Subpackage P2 - nsURI: http://b, no classifiers
>>>>> Subsubpackage P3 - nsURI: http://c, classifier C3
>>>> Why do you care to have this nesting? Why not just have separate
>>>> packages who's qualified names happen to induce this tree?
>>>>>
>>>>> I've tried to get a reference to C3 with
>>>>> http://c#//C3
>>>>> or
>>>>> http://a#//P2/P3/C3.
>>>>> Both attempts were not successfull. It turns out, that
>>>>> EcoreUtil.getURI(Subsubpackage.Literals.C3) returns http://a#//P3/C3.
>>>> I expect http://c#//C3 to resolve though but maybe I'm assuming
>>>> changes
>>>> made in 2.5 (to create a resource for subpackages). Which version
>>>> of EMF
>>>> are you using?
>>>>> Digging through the code of the generator reveals that empty packages
>>>>> will not be generated. This leads to the given, modified containment
>>>>> hierarchy, that will produce the unexpected (at least by me) URI.
>>>>>
>>>>> The question is:
>>>>> How can I predict the URI of a generated EClass with respect to
>>>>> nested
>>>>> packages, cross resource containment and all other fancy
>>>>> optimizations
>>>>> that may happen in the Ecore generator?
>>>> Add a dummy classifier, and it's more predictable.
>>>>>
>>>>> Thanks,
>>>>> Sebastian
>>>>>
>>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: URI of Classifiers in subpackages [message #430815 is a reply to message #430803] |
Thu, 11 June 2009 09:15 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Sebastian,
Of course I realize now I can't test this myself because I don't have
your models.
I mentioned that I don't recall if a resource is created for a generated
subpackage or not... Because cross resource containment is supported,
it makes sense to create one, and I know I discussed that with Dave, but
I don't recall if it was done. I'd have to go look. :-P
Of course all this reiterates why subpackages are not fun...
So in the end, perhaps you want to create the path by starting at the
root package, using its nsURI, and computing the path down through the
packages, dropping the segments for the packages without classifiers.
Sebastian Zarnekow wrote:
> Hi Ed,
>
> I've got the following two testcases. The first one is green while the
> second will fail on the last line.
> I assume that I'm missing something fundamental here ...
>
> public void testUriFormat() throws Exception {
> URI uri =
> EcoreUtil.getURI(SubsubpackagePackage.Literals.ANOTHER_TYPE) ;
> assertTrue(AmetamodelPackage.eNS_URI.equals(uri.trimFragment ().toString()));
>
> ResourceSet set = new ResourceSetImpl();
> EObject eObject = set.getEObject(uri, true);
> assertSame(SubsubpackagePackage.Literals.ANOTHER_TYPE, eObject);
> }
>
> public void testUriFormat2() throws Exception {
> URI uri = URI.createURI(SubsubpackagePackage.eNS_URI + "#//" +
> SubsubpackagePackage.Literals.ANOTHER_TYPE.getName());
> assertTrue(EPackage.Registry.INSTANCE.containsKey(Subsubpack agePackage.eNS_URI));
>
> assertFalse(EcoreUtil.getURI(SubsubpackagePackage.Literals.A NOTHER_TYPE).equals(uri));
>
> ResourceSet set = new ResourceSetImpl();
> EObject eObject = set.getEObject(uri, true);
> assertSame(SubsubpackagePackage.Literals.ANOTHER_TYPE, eObject);
> // fail
> }
>
> Your help is very appreciated,
> Sebastian
>
> Am 10.06.2009 22:12 Uhr, schrieb Sebastian Zarnekow:
>> Hi Ed,
>>
>> I'm trying to fix a bug in Xtext, that occures in the rare case of empty
>> subpackages. I have not any influence on the structure of the metamodel,
>> nor do I like the idea of subpackages at all...
>>
>> http://c#/c3 did not resolve for me, but I'll try again. Xtext requires
>> EMF 2.5, so I hope this will work.
>>
>> Thanks for your help,
>> Sebastian
>>
>>
>> Am 10.06.2009 21:57 Uhr, schrieb Ed Merks:
>>> Sebastian,
>>>
>>> Comments below.
>>>
>>> Sebastian Zarnekow wrote:
>>>> Hi,
>>>>
>>>> I've searched the FAQ for this one, but have not had any success.
>>>>
>>>> Given an EPackage with a number of classifiers and subpackages
>>> Oh joy. I'm not sure why people are so enamored with subpackages, given
>>> they provide no substantial value and and yet tend to cause problems...
>>>> which may or may not contain other classifiers, is there a way to
>>>> compute the URI (-fragment) that will resolve to a specific classifier
>>>> when the model code will be generated by the Ecore generator?
>>> You're aware of https://bugs.eclipse.org/bugs/show_bug.cgi?id=142856 I
>>> guess? If you really want a package to be generated, put in a dummy
>>> EDataType as a workaround.
>>>>
>>>> Example:
>>>>
>>>> EPackage P1 - nsURI: http://a, classifiers C1, C2
>>>> Subpackage P2 - nsURI: http://b, no classifiers
>>>> Subsubpackage P3 - nsURI: http://c, classifier C3
>>> Why do you care to have this nesting? Why not just have separate
>>> packages who's qualified names happen to induce this tree?
>>>>
>>>> I've tried to get a reference to C3 with
>>>> http://c#//C3
>>>> or
>>>> http://a#//P2/P3/C3.
>>>> Both attempts were not successfull. It turns out, that
>>>> EcoreUtil.getURI(Subsubpackage.Literals.C3) returns http://a#//P3/C3.
>>> I expect http://c#//C3 to resolve though but maybe I'm assuming changes
>>> made in 2.5 (to create a resource for subpackages). Which version of
>>> EMF
>>> are you using?
>>>> Digging through the code of the generator reveals that empty packages
>>>> will not be generated. This leads to the given, modified containment
>>>> hierarchy, that will produce the unexpected (at least by me) URI.
>>>>
>>>> The question is:
>>>> How can I predict the URI of a generated EClass with respect to nested
>>>> packages, cross resource containment and all other fancy optimizations
>>>> that may happen in the Ecore generator?
>>> Add a dummy classifier, and it's more predictable.
>>>>
>>>> Thanks,
>>>> Sebastian
>>>>
>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: URI of Classifiers in subpackages [message #430818 is a reply to message #430815] |
Thu, 11 June 2009 10:53 |
Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
thanks for your help and the suggestion.
Let's transform the simplified sample into the concrete situation.
We parse an Xtext grammar, link returns types of production rules to
EClasses and serialize the grammar. It may be the situation, that we do
this linking to classifiers from ecore resources that are not installed
in the current workspace.
What we basically do is:
0. Create a resource set and use it later on as "copy-target".
1. Parse Xtext grammar with Xtext Parser
2. Load ecore resources and link EClassifiers
3. Copy parsed / linked grammar into XMI resource.
4. Copy any root-EPackage into a new Resource, set resource uri to
EPackage-nsURI.
5. Redirect references to EClassifiers.
6. Save the xmi-resource.
Later on, someone will install the metamodels and try to load the
xmi-file, which will lead to unresolved proxies, at the moment (in the
rare case of empty subpackages ...)
Is there a hook, that I can use to modify the, that is used to refer to
EClassifiers?
Do I have to put a custom resource factory into the ResourceSet, that is
the target set for all copied EObjects, use this one for ecore-resources
and override "getFragmentURI"? Or is there an easier way?
Regards,
Sebastian
Am 11.06.2009 11:15 Uhr, schrieb Ed Merks:
> Sebastian,
>
> Of course I realize now I can't test this myself because I don't have
> your models.
>
> I mentioned that I don't recall if a resource is created for a generated
> subpackage or not... Because cross resource containment is supported, it
> makes sense to create one, and I know I discussed that with Dave, but I
> don't recall if it was done. I'd have to go look. :-P
>
> Of course all this reiterates why subpackages are not fun...
>
> So in the end, perhaps you want to create the path by starting at the
> root package, using its nsURI, and computing the path down through the
> packages, dropping the segments for the packages without classifiers.
>
>
> Sebastian Zarnekow wrote:
>> Hi Ed,
>>
>> I've got the following two testcases. The first one is green while the
>> second will fail on the last line.
>> I assume that I'm missing something fundamental here ...
>>
>> public void testUriFormat() throws Exception {
>> URI uri = EcoreUtil.getURI(SubsubpackagePackage.Literals.ANOTHER_TYPE) ;
>> assertTrue(AmetamodelPackage.eNS_URI.equals(uri.trimFragment ().toString()));
>>
>> ResourceSet set = new ResourceSetImpl();
>> EObject eObject = set.getEObject(uri, true);
>> assertSame(SubsubpackagePackage.Literals.ANOTHER_TYPE, eObject);
>> }
>>
>> public void testUriFormat2() throws Exception {
>> URI uri = URI.createURI(SubsubpackagePackage.eNS_URI + "#//" +
>> SubsubpackagePackage.Literals.ANOTHER_TYPE.getName());
>> assertTrue(EPackage.Registry.INSTANCE.containsKey(Subsubpack agePackage.eNS_URI));
>>
>> assertFalse(EcoreUtil.getURI(SubsubpackagePackage.Literals.A NOTHER_TYPE).equals(uri));
>>
>> ResourceSet set = new ResourceSetImpl();
>> EObject eObject = set.getEObject(uri, true);
>> assertSame(SubsubpackagePackage.Literals.ANOTHER_TYPE, eObject); // fail
>> }
>>
>> Your help is very appreciated,
>> Sebastian
>>
>> Am 10.06.2009 22:12 Uhr, schrieb Sebastian Zarnekow:
>>> Hi Ed,
>>>
>>> I'm trying to fix a bug in Xtext, that occures in the rare case of empty
>>> subpackages. I have not any influence on the structure of the metamodel,
>>> nor do I like the idea of subpackages at all...
>>>
>>> http://c#/c3 did not resolve for me, but I'll try again. Xtext requires
>>> EMF 2.5, so I hope this will work.
>>>
>>> Thanks for your help,
>>> Sebastian
>>>
>>>
>>> Am 10.06.2009 21:57 Uhr, schrieb Ed Merks:
>>>> Sebastian,
>>>>
>>>> Comments below.
>>>>
>>>> Sebastian Zarnekow wrote:
>>>>> Hi,
>>>>>
>>>>> I've searched the FAQ for this one, but have not had any success.
>>>>>
>>>>> Given an EPackage with a number of classifiers and subpackages
>>>> Oh joy. I'm not sure why people are so enamored with subpackages, given
>>>> they provide no substantial value and and yet tend to cause problems...
>>>>> which may or may not contain other classifiers, is there a way to
>>>>> compute the URI (-fragment) that will resolve to a specific classifier
>>>>> when the model code will be generated by the Ecore generator?
>>>> You're aware of https://bugs.eclipse.org/bugs/show_bug.cgi?id=142856 I
>>>> guess? If you really want a package to be generated, put in a dummy
>>>> EDataType as a workaround.
>>>>>
>>>>> Example:
>>>>>
>>>>> EPackage P1 - nsURI: http://a, classifiers C1, C2
>>>>> Subpackage P2 - nsURI: http://b, no classifiers
>>>>> Subsubpackage P3 - nsURI: http://c, classifier C3
>>>> Why do you care to have this nesting? Why not just have separate
>>>> packages who's qualified names happen to induce this tree?
>>>>>
>>>>> I've tried to get a reference to C3 with
>>>>> http://c#//C3
>>>>> or
>>>>> http://a#//P2/P3/C3.
>>>>> Both attempts were not successfull. It turns out, that
>>>>> EcoreUtil.getURI(Subsubpackage.Literals.C3) returns http://a#//P3/C3.
>>>> I expect http://c#//C3 to resolve though but maybe I'm assuming changes
>>>> made in 2.5 (to create a resource for subpackages). Which version of
>>>> EMF
>>>> are you using?
>>>>> Digging through the code of the generator reveals that empty packages
>>>>> will not be generated. This leads to the given, modified containment
>>>>> hierarchy, that will produce the unexpected (at least by me) URI.
>>>>>
>>>>> The question is:
>>>>> How can I predict the URI of a generated EClass with respect to nested
>>>>> packages, cross resource containment and all other fancy optimizations
>>>>> that may happen in the Ecore generator?
>>>> Add a dummy classifier, and it's more predictable.
>>>>>
>>>>> Thanks,
>>>>> Sebastian
>>>>>
>>>
>>
|
|
|
| Re: URI of Classifiers in subpackages [message #430825 is a reply to message #430818] |
Thu, 11 June 2009 12:58 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------050902010705060308020909
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Sebastian,
Comments below.
Sebastian Zarnekow wrote:
> Hi Ed,
>
> thanks for your help and the suggestion.
>
> Let's transform the simplified sample into the concrete situation.
>
> We parse an Xtext grammar, link returns types of production rules to
> EClasses and serialize the grammar. It may be the situation, that we
> do this linking to classifiers from ecore resources that are not
> installed in the current workspace.
>
> What we basically do is:
>
> 0. Create a resource set and use it later on as "copy-target".
> 1. Parse Xtext grammar with Xtext Parser
> 2. Load ecore resources and link EClassifiers
> 3. Copy parsed / linked grammar into XMI resource.
> 4. Copy any root-EPackage into a new Resource, set resource uri to
> EPackage-nsURI.
So the copied grammer refers to the copied packages?
> 5. Redirect references to EClassifiers.
It sounds like maybe you should be using a single Copier instance that
that copies the packages and grammers all at once...
> 6. Save the xmi-resource.
Note also that something like this option can be used to swizzle URIs
perhaps without need for copying anything...
/**
* A {@link URIHandler} value that will be used to control how
URIs are {@link URI#resolve(URI) resolved} during load
* and {@link URI#deresolve(URI) deresolved} during save.
* @see URI
* @see URIHandler
* @see XMLHelper#resolve(URI, URI)
* @see XMLHelper#deresolve(URI)
* @see URIHandlerImpl
*/
String OPTION_URI_HANDLER = "URI_HANDLER";
>
> Later on, someone will install the metamodels and try to load the
> xmi-file, which will lead to unresolved proxies, at the moment (in the
> rare case of empty subpackages ...)
Just tell people it's not supported and point them at the EMF bugzilla
that will hopefully one day be addressed.
>
> Is there a hook, that I can use to modify the, that is used to refer
> to EClassifiers?
The URI handler might help.
> Do I have to put a custom resource factory into the ResourceSet, that
> is the target set for all copied EObjects, use this one for
> ecore-resources and override "getFragmentURI"? Or is there an easier way?
Tell them it's not supported. :-P Put a dummy classifier in the package
or don't use nested packages...
>
> Regards,
> Sebastian
>
> Am 11.06.2009 11:15 Uhr, schrieb Ed Merks:
>> Sebastian,
>>
>> Of course I realize now I can't test this myself because I don't have
>> your models.
>>
>> I mentioned that I don't recall if a resource is created for a generated
>> subpackage or not... Because cross resource containment is supported, it
>> makes sense to create one, and I know I discussed that with Dave, but I
>> don't recall if it was done. I'd have to go look. :-P
>>
>> Of course all this reiterates why subpackages are not fun...
>>
>> So in the end, perhaps you want to create the path by starting at the
>> root package, using its nsURI, and computing the path down through the
>> packages, dropping the segments for the packages without classifiers.
>>
>>
>> Sebastian Zarnekow wrote:
>>> Hi Ed,
>>>
>>> I've got the following two testcases. The first one is green while the
>>> second will fail on the last line.
>>> I assume that I'm missing something fundamental here ...
>>>
>>> public void testUriFormat() throws Exception {
>>> URI uri = EcoreUtil.getURI(SubsubpackagePackage.Literals.ANOTHER_TYPE) ;
>>> assertTrue(AmetamodelPackage.eNS_URI.equals(uri.trimFragment ().toString()));
>>>
>>>
>>> ResourceSet set = new ResourceSetImpl();
>>> EObject eObject = set.getEObject(uri, true);
>>> assertSame(SubsubpackagePackage.Literals.ANOTHER_TYPE, eObject);
>>> }
>>>
>>> public void testUriFormat2() throws Exception {
>>> URI uri = URI.createURI(SubsubpackagePackage.eNS_URI + "#//" +
>>> SubsubpackagePackage.Literals.ANOTHER_TYPE.getName());
>>> assertTrue(EPackage.Registry.INSTANCE.containsKey(Subsubpack agePackage.eNS_URI));
>>>
>>>
>>> assertFalse(EcoreUtil.getURI(SubsubpackagePackage.Literals.A NOTHER_TYPE).equals(uri));
>>>
>>>
>>> ResourceSet set = new ResourceSetImpl();
>>> EObject eObject = set.getEObject(uri, true);
>>> assertSame(SubsubpackagePackage.Literals.ANOTHER_TYPE, eObject); //
>>> fail
>>> }
>>>
>>> Your help is very appreciated,
>>> Sebastian
>>>
>>> Am 10.06.2009 22:12 Uhr, schrieb Sebastian Zarnekow:
>>>> Hi Ed,
>>>>
>>>> I'm trying to fix a bug in Xtext, that occures in the rare case of
>>>> empty
>>>> subpackages. I have not any influence on the structure of the
>>>> metamodel,
>>>> nor do I like the idea of subpackages at all...
>>>>
>>>> http://c#/c3 did not resolve for me, but I'll try again. Xtext
>>>> requires
>>>> EMF 2.5, so I hope this will work.
>>>>
>>>> Thanks for your help,
>>>> Sebastian
>>>>
>>>>
>>>> Am 10.06.2009 21:57 Uhr, schrieb Ed Merks:
>>>>> Sebastian,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Sebastian Zarnekow wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I've searched the FAQ for this one, but have not had any success.
>>>>>>
>>>>>> Given an EPackage with a number of classifiers and subpackages
>>>>> Oh joy. I'm not sure why people are so enamored with subpackages,
>>>>> given
>>>>> they provide no substantial value and and yet tend to cause
>>>>> problems...
>>>>>> which may or may not contain other classifiers, is there a way to
>>>>>> compute the URI (-fragment) that will resolve to a specific
>>>>>> classifier
>>>>>> when the model code will be generated by the Ecore generator?
>>>>> You're aware of
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=142856 I
>>>>> guess? If you really want a package to be generated, put in a dummy
>>>>> EDataType as a workaround.
>>>>>>
>>>>>> Example:
>>>>>>
>>>>>> EPackage P1 - nsURI: http://a, classifiers C1, C2
>>>>>> Subpackage P2 - nsURI: http://b, no classifiers
>>>>>> Subsubpackage P3 - nsURI: http://c, classifier C3
>>>>> Why do you care to have this nesting? Why not just have separate
>>>>> packages who's qualified names happen to induce this tree?
>>>>>>
>>>>>> I've tried to get a reference to C3 with
>>>>>> http://c#//C3
>>>>>> or
>>>>>> http://a#//P2/P3/C3.
>>>>>> Both attempts were not successfull. It turns out, that
>>>>>> EcoreUtil.getURI(Subsubpackage.Literals.C3) returns
>>>>>> http://a#//P3/C3.
>>>>> I expect http://c#//C3 to resolve though but maybe I'm assuming
>>>>> changes
>>>>> made in 2.5 (to create a resource for subpackages). Which version of
>>>>> EMF
>>>>> are you using?
>>>>>> Digging through the code of the generator reveals that empty
>>>>>> packages
>>>>>> will not be generated. This leads to the given, modified containment
>>>>>> hierarchy, that will produce the unexpected (at least by me) URI.
>>>>>>
>>>>>> The question is:
>>>>>> How can I predict the URI of a generated EClass with respect to
>>>>>> nested
>>>>>> packages, cross resource containment and all other fancy
>>>>>> optimizations
>>>>>> that may happen in the Ecore generator?
>>>>> Add a dummy classifier, and it's more predictable.
>>>>>>
>>>>>> Thanks,
>>>>>> Sebastian
>>>>>>
>>>>
>>>
>
--------------050902010705060308020909
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Sebastian,<br>
<br>
Comments below.<br>
<br>
<br>
Sebastian Zarnekow wrote:
<blockquote cite="mid:h0qnna$qus$1@build.eclipse.org" type="cite">Hi
Ed,
<br>
<br>
thanks for your help and the suggestion.
<br>
<br>
Let's transform the simplified sample into the concrete situation.
<br>
<br>
We parse an Xtext grammar, link returns types of production rules to
EClasses and serialize the grammar. It may be the situation, that we do
this linking to classifiers from ecore resources that are not installed
in the current workspace.
<br>
<br>
What we basically do is:
<br>
<br>
0. Create a resource set and use it later on as "copy-target".
<br>
1. Parse Xtext grammar with Xtext Parser
<br>
2. Load ecore resources and link EClassifiers
<br>
3. Copy parsed / linked grammar into XMI resource.
<br>
4. Copy any root-EPackage into a new Resource, set resource uri to
EPackage-nsURI.
<br>
</blockquote>
So the copied grammer refers to the copied packages?<br>
<blockquote cite="mid:h0qnna$qus$1@build.eclipse.org" type="cite">5.
Redirect references to EClassifiers.
<br>
</blockquote>
It sounds like maybe you should be using a single Copier instance that
that copies the packages and grammers all at once...<br>
<blockquote cite="mid:h0qnna$qus$1@build.eclipse.org" type="cite">6.
Save the xmi-resource.
<br>
</blockquote>
Note also that something like this option can be used to swizzle URIs
perhaps without need for copying anything...<br>
<blockquote>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: URI of Classifiers in subpackages [message #430829 is a reply to message #430825] |
Thu, 11 June 2009 13:47 |
Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Thanks for your help,
actually I'm already using a single copier instance.
I'll have a look into the OPTION_URI_HANDLER.
Regards,
Sebastian
Am 11.06.2009 14:58 Uhr, schrieb Ed Merks:
> Sebastian,
>
> Comments below.
>
>
> Sebastian Zarnekow wrote:
>> Hi Ed,
>>
>> thanks for your help and the suggestion.
>>
>> Let's transform the simplified sample into the concrete situation.
>>
>> We parse an Xtext grammar, link returns types of production rules to
>> EClasses and serialize the grammar. It may be the situation, that we
>> do this linking to classifiers from ecore resources that are not
>> installed in the current workspace.
>>
>> What we basically do is:
>>
>> 0. Create a resource set and use it later on as "copy-target".
>> 1. Parse Xtext grammar with Xtext Parser
>> 2. Load ecore resources and link EClassifiers
>> 3. Copy parsed / linked grammar into XMI resource.
>> 4. Copy any root-EPackage into a new Resource, set resource uri to
>> EPackage-nsURI.
> So the copied grammer refers to the copied packages?
>> 5. Redirect references to EClassifiers.
> It sounds like maybe you should be using a single Copier instance that
> that copies the packages and grammers all at once...
>> 6. Save the xmi-resource.
> Note also that something like this option can be used to swizzle URIs
> perhaps without need for copying anything...
>
> /**
> * A {@link URIHandler} value that will be used to control how
> URIs are {@link URI#resolve(URI) resolved} during load
> * and {@link URI#deresolve(URI) deresolved} during save.
> * @see URI
> * @see URIHandler
> * @see XMLHelper#resolve(URI, URI)
> * @see XMLHelper#deresolve(URI)
> * @see URIHandlerImpl
> */
> String OPTION_URI_HANDLER = "URI_HANDLER";
>
>>
>> Later on, someone will install the metamodels and try to load the
>> xmi-file, which will lead to unresolved proxies, at the moment (in the
>> rare case of empty subpackages ...)
> Just tell people it's not supported and point them at the EMF bugzilla
> that will hopefully one day be addressed.
>>
>> Is there a hook, that I can use to modify the, that is used to refer
>> to EClassifiers?
> The URI handler might help.
>> Do I have to put a custom resource factory into the ResourceSet, that
>> is the target set for all copied EObjects, use this one for
>> ecore-resources and override "getFragmentURI"? Or is there an easier way?
> Tell them it's not supported. :-P Put a dummy classifier in the package
> or don't use nested packages...
>>
>> Regards,
>> Sebastian
>>
>> Am 11.06.2009 11:15 Uhr, schrieb Ed Merks:
>>> Sebastian,
>>>
>>> Of course I realize now I can't test this myself because I don't have
>>> your models.
>>>
>>> I mentioned that I don't recall if a resource is created for a generated
>>> subpackage or not... Because cross resource containment is supported, it
>>> makes sense to create one, and I know I discussed that with Dave, but I
>>> don't recall if it was done. I'd have to go look. :-P
>>>
>>> Of course all this reiterates why subpackages are not fun...
>>>
>>> So in the end, perhaps you want to create the path by starting at the
>>> root package, using its nsURI, and computing the path down through the
>>> packages, dropping the segments for the packages without classifiers.
>>>
>>>
>>> Sebastian Zarnekow wrote:
>>>> Hi Ed,
>>>>
>>>> I've got the following two testcases. The first one is green while the
>>>> second will fail on the last line.
>>>> I assume that I'm missing something fundamental here ...
>>>>
>>>> public void testUriFormat() throws Exception {
>>>> URI uri = EcoreUtil.getURI(SubsubpackagePackage.Literals.ANOTHER_TYPE) ;
>>>> assertTrue(AmetamodelPackage.eNS_URI.equals(uri.trimFragment ().toString()));
>>>>
>>>>
>>>> ResourceSet set = new ResourceSetImpl();
>>>> EObject eObject = set.getEObject(uri, true);
>>>> assertSame(SubsubpackagePackage.Literals.ANOTHER_TYPE, eObject);
>>>> }
>>>>
>>>> public void testUriFormat2() throws Exception {
>>>> URI uri = URI.createURI(SubsubpackagePackage.eNS_URI + "#//" +
>>>> SubsubpackagePackage.Literals.ANOTHER_TYPE.getName());
>>>> assertTrue(EPackage.Registry.INSTANCE.containsKey(Subsubpack agePackage.eNS_URI));
>>>>
>>>>
>>>> assertFalse(EcoreUtil.getURI(SubsubpackagePackage.Literals.A NOTHER_TYPE).equals(uri));
>>>>
>>>>
>>>> ResourceSet set = new ResourceSetImpl();
>>>> EObject eObject = set.getEObject(uri, true);
>>>> assertSame(SubsubpackagePackage.Literals.ANOTHER_TYPE, eObject); //
>>>> fail
>>>> }
>>>>
>>>> Your help is very appreciated,
>>>> Sebastian
>>>>
>>>> Am 10.06.2009 22:12 Uhr, schrieb Sebastian Zarnekow:
>>>>> Hi Ed,
>>>>>
>>>>> I'm trying to fix a bug in Xtext, that occures in the rare case of
>>>>> empty
>>>>> subpackages. I have not any influence on the structure of the
>>>>> metamodel,
>>>>> nor do I like the idea of subpackages at all...
>>>>>
>>>>> http://c#/c3 did not resolve for me, but I'll try again. Xtext
>>>>> requires
>>>>> EMF 2.5, so I hope this will work.
>>>>>
>>>>> Thanks for your help,
>>>>> Sebastian
>>>>>
>>>>>
>>>>> Am 10.06.2009 21:57 Uhr, schrieb Ed Merks:
>>>>>> Sebastian,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>> Sebastian Zarnekow wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I've searched the FAQ for this one, but have not had any success.
>>>>>>>
>>>>>>> Given an EPackage with a number of classifiers and subpackages
>>>>>> Oh joy. I'm not sure why people are so enamored with subpackages,
>>>>>> given
>>>>>> they provide no substantial value and and yet tend to cause
>>>>>> problems...
>>>>>>> which may or may not contain other classifiers, is there a way to
>>>>>>> compute the URI (-fragment) that will resolve to a specific
>>>>>>> classifier
>>>>>>> when the model code will be generated by the Ecore generator?
>>>>>> You're aware of
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=142856 I
>>>>>> guess? If you really want a package to be generated, put in a dummy
>>>>>> EDataType as a workaround.
>>>>>>>
>>>>>>> Example:
>>>>>>>
>>>>>>> EPackage P1 - nsURI: http://a, classifiers C1, C2
>>>>>>> Subpackage P2 - nsURI: http://b, no classifiers
>>>>>>> Subsubpackage P3 - nsURI: http://c, classifier C3
>>>>>> Why do you care to have this nesting? Why not just have separate
>>>>>> packages who's qualified names happen to induce this tree?
>>>>>>>
>>>>>>> I've tried to get a reference to C3 with
>>>>>>> http://c#//C3
>>>>>>> or
>>>>>>> http://a#//P2/P3/C3.
>>>>>>> Both attempts were not successfull. It turns out, that
>>>>>>> EcoreUtil.getURI(Subsubpackage.Literals.C3) returns
>>>>>>> http://a#//P3/C3.
>>>>>> I expect http://c#//C3 to resolve though but maybe I'm assuming
>>>>>> changes
>>>>>> made in 2.5 (to create a resource for subpackages). Which version of
>>>>>> EMF
>>>>>> are you using?
>>>>>>> Digging through the code of the generator reveals that empty
>>>>>>> packages
>>>>>>> will not be generated. This leads to the given, modified containment
>>>>>>> hierarchy, that will produce the unexpected (at least by me) URI.
>>>>>>>
>>>>>>> The question is:
>>>>>>> How can I predict the URI of a generated EClass with respect to
>>>>>>> nested
>>>>>>> packages, cross resource containment and all other fancy
>>>>>>> optimizations
>>>>>>> that may happen in the Ecore generator?
>>>>>> Add a dummy classifier, and it's more predictable.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Sebastian
>>>>>>>
>>>>>
>>>>
>>
|
|
|
Goto Forum:
Current Time: Sat Apr 27 01:06:10 GMT 2024
Powered by FUDForum. Page generated in 0.03581 seconds |
] 
Search
Help
Register
Login
Home
