Home » Modeling » EMF » [EMF] EAnnotation references in sub-packages of empty package(Code gen seems unaware of inexistence of empty base package)
| [EMF] EAnnotation references in sub-packages of empty package [message #1289954] |
Wed, 09 April 2014 20:02  |
 Olivier Labrosse
Messages: 49
Registered: November 2011 |
Member |
|
|
Hi,
I have an ecore where a root "foo" package is empty except for a few sub-packages. One of the sub-packages, "bar", defines an EClass, "BarItem", with an EAnnotation. If the EAnnotation's source is "foobar" and its references point to the BazItem EClass in another sub-package called baz, BarPackageImpl will contain the following method:
protected void createFoobarAnnotations() {
String source = "foobar"; //$NON-NLS-1$
addAnnotation
(barItemEClass,
source,
new String[] {
},
new URI[] {
URI.createURI(FooPackage.eNS_URI).appendFragment("//baz/BazItem") //$NON-NLS-1$
});
}
The problem is that FooPackage (the root package) is not generated, seemingly due to being empty.
Am I doing something wrong, or should the generator either inline the URI string or create the root package classes even though it is empty?
Thank you!
-Olivier
|
|
|
| Re: [EMF] EAnnotation references in sub-packages of empty package [message #1290778 is a reply to message #1289954] |
Thu, 10 April 2014 12:27  |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Olivier,
Comments below.
On 09/04/2014 10:02 PM, Olivier Labrosse wrote:
> Hi,
>
> I have an ecore where a root "foo" package is empty except for a few
> sub-packages.
Subpackages are evil.
> One of the sub-packages, "bar", defines an EClass, "BarItem", with an
> EAnnotation. If the EAnnotation's source is "foobar" and its
> references point to the BazItem EClass in another sub-package called
> baz, BarPackageImpl will contain the following method:
>
>
> protected void createFoobarAnnotations() {
> String source = "foobar"; //$NON-NLS-1$
> addAnnotation
> (barItemEClass, source, new String[] {
> },
> new URI[] {
> URI.createURI(FooPackage.eNS_URI).appendFragment("//baz/BazItem")
> //$NON-NLS-1$
> });
> }
>
>
> The problem is that FooPackage (the root package) is not generated,
> seemingly due to being empty.
Yes. Does it generate something that fails to compile?
>
> Am I doing something wrong, or should the generator either inline the
> URI string or create the root package classes even though it is empty?
It should use the package that contains the BazItem EClass. If that's
not the case, please open a bugzilla (and be reminded that subpackages
are evil because there's always yet another corner case that some tool
won't handle well).
>
> Thank you!
>
> -Olivier
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [EMF] EAnnotation references in sub-packages of empty package [message #1290822 is a reply to message #1290778] |
Thu, 10 April 2014 13:17 |
Olivier Labrosse
Messages: 49
Registered: November 2011 |
Member |
|
|
Thank you Ed. Please see comments below.
Ed Merks wrote on Thu, 10 April 2014 08:27Olivier,
Comments below.
On 09/04/2014 10:02 PM, Olivier Labrosse wrote:
> Hi,
>
> I have an ecore where a root "foo" package is empty except for a few
> sub-packages.
Subpackages are evil.
> One of the sub-packages, "bar", defines an EClass, "BarItem", with an
> EAnnotation. If the EAnnotation's source is "foobar" and its
> references point to the BazItem EClass in another sub-package called
> baz, BarPackageImpl will contain the following method:
>
>
> protected void createFoobarAnnotations() {
> String source = "foobar"; //$NON-NLS-1$
> addAnnotation
> (barItemEClass, source, new String[] {
> },
> new URI[] {
> URI.createURI(FooPackage.eNS_URI).appendFragment("//baz/BazItem")
> //$NON-NLS-1$
> });
> }
>
>
> The problem is that FooPackage (the root package) is not generated,
> seemingly due to being empty.
Yes. Does it generate something that fails to compile?
Sorry I wasn't more precise. FooPackage.eNS_URI is the problem, since FooPackage doesn't exist. Indeed, it fails to compile.
Quote:> Am I doing something wrong, or should the generator either inline the
> URI string or create the root package classes even though it is empty?
It should use the package that contains the BazItem EClass. If that's
not the case, please open a bugzilla (and be reminded that subpackages
are evil because there's always yet another corner case that some tool
won't handle well).
Will do. Thanks again!
|
|
|
| Re: [EMF] EAnnotation references in sub-packages of empty package [message #1290852 is a reply to message #1290822] |
Thu, 10 April 2014 13:45 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
EMF (and other tools) really hate EPackages with null nsURIs or null
names and sometimes even null nsPrefixes.
GIT\org.eclipse.ocl\plugins\org.eclipse.ocl\model\OCL.ecore
is almost what you describe and has been working for years.
Regards
Ed Willink
On 10/04/2014 14:17, Olivier Labrosse wrote:
> Thank you Ed. Please see comments below.
>
> Ed Merks wrote on Thu, 10 April 2014 08:27
>> Olivier,
>>
>> Comments below.
>>
>> On 09/04/2014 10:02 PM, Olivier Labrosse wrote:
>> > Hi,
>> >
>> > I have an ecore where a root "foo" package is empty except for a
>> few > sub-packages.
>> Subpackages are evil.
>> > One of the sub-packages, "bar", defines an EClass, "BarItem", with
>> an > EAnnotation. If the EAnnotation's source is "foobar" and its >
>> references point to the BazItem EClass in another sub-package called
>> > baz, BarPackageImpl will contain the following method:
>> >
>> >
>> > protected void createFoobarAnnotations() {
>> > String source = "foobar"; //$NON-NLS-1$
>> > addAnnotation
>> > (barItemEClass, source, new String[] {
>> > },
>> > new URI[] {
>> > URI.createURI(FooPackage.eNS_URI).appendFragment("//baz/BazItem") >
>> //$NON-NLS-1$
>> > });
>> > }
>> >
>> >
>> > The problem is that FooPackage (the root package) is not generated,
>> > seemingly due to being empty.
>> Yes. Does it generate something that fails to compile?
>
> Sorry I wasn't more precise. FooPackage.eNS_URI is the problem, since
> FooPackage doesn't exist. Indeed, it fails to compile.
>
>
> Quote:
>> > Am I doing something wrong, or should the generator either inline
>> the > URI string or create the root package classes even though it is
>> empty?
>> It should use the package that contains the BazItem EClass. If
>> that's not the case, please open a bugzilla (and be reminded that
>> subpackages are evil because there's always yet another corner case
>> that some tool won't handle well).
>
> Will do. Thanks again!
|
|
|
| Re: [EMF] EAnnotation references in sub-packages of empty package [message #1290970 is a reply to message #1290852] |
Thu, 10 April 2014 15:46 |
|
Hi, Ed,
Demand-created packages (for unrecognized content using EMF's XML
AnyTypes) always have null names, though they generally have nsPrefixes
(in qualified XML content). Which tools don't work with null package
names?
Cheers,
Christian
On 2014-04-10 13:45:21 +0000, Ed Willink said:
> Hi
>
> EMF (and other tools) really hate EPackages with null nsURIs or null
> names and sometimes even null nsPrefixes.
>
> GIT\org.eclipse.ocl\plugins\org.eclipse.ocl\model\OCL.ecore
>
> is almost what you describe and has been working for years.
>
> Regards
>
> Ed Willink
>
>
> On 10/04/2014 14:17, Olivier Labrosse wrote:
>> Thank you Ed. Please see comments below.
>>
>> Ed Merks wrote on Thu, 10 April 2014 08:27
>>> Olivier,
>>>
>>> Comments below.
>>>
>>> On 09/04/2014 10:02 PM, Olivier Labrosse wrote:
>>>> Hi,
>>>>
>>>> I have an ecore where a root "foo" package is empty except for a
>>> few > sub-packages.
>>> Subpackages are evil.
>>>> One of the sub-packages, "bar", defines an EClass, "BarItem", with
>>> an > EAnnotation. If the EAnnotation's source is "foobar" and its >
>>> references point to the BazItem EClass in another sub-package called
>>>> baz, BarPackageImpl will contain the following method:
>>>>
>>>>
>>>> protected void createFoobarAnnotations() {
>>>> String source = "foobar"; //$NON-NLS-1$
>>>> addAnnotation
>>>> (barItemEClass, source, new String[] {
>>>> },
>>>> new URI[] {
>>>> URI.createURI(FooPackage.eNS_URI).appendFragment("//baz/BazItem") >
>>> //$NON-NLS-1$
>>>> });
>>>> }
>>>>
>>>>
>>>> The problem is that FooPackage (the root package) is not generated,
>>>> seemingly due to being empty.
>>> Yes. Does it generate something that fails to compile?
>>
>> Sorry I wasn't more precise. FooPackage.eNS_URI is the problem, since
>> FooPackage doesn't exist. Indeed, it fails to compile.
>>
>>
>> Quote:
>>>> Am I doing something wrong, or should the generator either inline
>>> the > URI string or create the root package classes even though it is empty?
>>> It should use the package that contains the BazItem EClass. If that's
>>> not the case, please open a bugzilla (and be reminded that subpackages
>>> are evil because there's always yet another corner case that some tool
>>> won't handle well).
>>
>> Will do. Thanks again!
|
|
|
| Re: [EMF] EAnnotation references in sub-packages of empty package [message #1290993 is a reply to message #1290852] |
Thu, 10 April 2014 16:12 |
Olivier Labrosse
Messages: 49
Registered: November 2011 |
Member |
|
|
Hi Ed W.,
Thanks for the reply. I took a look and the EAnnotation references in OCL.ecore are under "contents" nodes that aren't output to the generated TypesPackageImpl, hence why OCL wouldn't share my problem.
One thing I did find in OCL.ecore that I thought might make a difference is the nsPrefixes. Mine didn't contain the base package nsPrefix like OCL's do. But after adding that base package nsPrefix and generating the code, nothing changed.
Note that all my packages, including the base one, have nsURIs, names and nsPrefixes.
Also note that the reason I'm using such EAnnotations is to define, in the meta-model, default model configurations by interface (i.e. EClass super-type). Maybe there's a better way to deal with this that I haven't considered yet? All I know is that, by my understanding, this should work.
Thanks again!
-Olivier
Ed Willink wrote on Thu, 10 April 2014 09:45Hi
EMF (and other tools) really hate EPackages with null nsURIs or null
names and sometimes even null nsPrefixes.
GIT\org.eclipse.ocl\plugins\org.eclipse.ocl\model\OCL.ecore
is almost what you describe and has been working for years.
Regards
Ed Willink
On 10/04/2014 14:17, Olivier Labrosse wrote:
> Thank you Ed. Please see comments below.
>
> Ed Merks wrote on Thu, 10 April 2014 08:27
>> Olivier,
>>
>> Comments below.
>>
>> On 09/04/2014 10:02 PM, Olivier Labrosse wrote:
>> > Hi,
>> >
>> > I have an ecore where a root "foo" package is empty except for a
>> few > sub-packages.
>> Subpackages are evil.
>> > One of the sub-packages, "bar", defines an EClass, "BarItem", with
>> an > EAnnotation. If the EAnnotation's source is "foobar" and its >
>> references point to the BazItem EClass in another sub-package called
>> > baz, BarPackageImpl will contain the following method:
>> >
>> >
>> > protected void createFoobarAnnotations() {
>> > String source = "foobar"; //$NON-NLS-1$
>> > addAnnotation
>> > (barItemEClass, source, new String[] {
>> > },
>> > new URI[] {
>> > URI.createURI(FooPackage.eNS_URI).appendFragment("//baz/BazItem") >
>> //$NON-NLS-1$
>> > });
>> > }
>> >
>> >
>> > The problem is that FooPackage (the root package) is not generated,
>> > seemingly due to being empty.
>> Yes. Does it generate something that fails to compile?
>
> Sorry I wasn't more precise. FooPackage.eNS_URI is the problem, since
> FooPackage doesn't exist. Indeed, it fails to compile.
>
>
> Quote:
>> > Am I doing something wrong, or should the generator either inline
>> the > URI string or create the root package classes even though it is
>> empty?
>> It should use the package that contains the BazItem EClass. If
>> that's not the case, please open a bugzilla (and be reminded that
>> subpackages are evil because there's always yet another corner case
>> that some tool won't handle well).
>
> Will do. Thanks again!
|
|
|
| Re: [EMF] EAnnotation references in sub-packages of empty package [message #1291007 is a reply to message #1290993] |
Thu, 10 April 2014 16:29 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
I'm confused. Your original report was about eNS_URI NPEs, hence the
recommendation about non null content.
Now I think you are commenting on inadequate EAnnotations for which I
have raised a couple of EMF bugs over the last couple of releases; the
first generated bad code for nested package annotations and was fixed.
The second generated inadequate code and was WONTFIXed, which is a
problem for those wanting to avoid run-time loading. So it awaits a user
contribution of the fix.
Regards
Ed Willink
On 10/04/2014 17:12, Olivier Labrosse wrote:
> Hi Ed W.,
>
> Thanks for the reply. I took a look and the EAnnotation references in
> OCL.ecore are under "contents" nodes that aren't output to the
> generated TypesPackageImpl, hence why OCL wouldn't share my problem.
>
> One thing I did find in OCL.ecore that I thought might make a
> difference is the nsPrefixes. Mine didn't contain the base package
> nsPrefix like OCL's do. But after adding that base package nsPrefix
> and generating the code, nothing changed.
>
> Note that all my packages, including the base one, have nsURIs, names
> and nsPrefixes.
>
> Also note that the reason I'm using such EAnnotations is to define, in
> the meta-model, default model configurations by interface (i.e. EClass
> super-type). Maybe there's a better way to deal with this that I
> haven't considered yet? All I know is that, by my understanding, this
> should work.
>
> Thanks again!
>
> -Olivier
> Ed Willink wrote on Thu, 10 April 2014 09:45
>> Hi
>>
>> EMF (and other tools) really hate EPackages with null nsURIs or null
>> names and sometimes even null nsPrefixes.
>>
>> GIT\org.eclipse.ocl\plugins\org.eclipse.ocl\model\OCL.ecore
>>
>> is almost what you describe and has been working for years.
>>
>> Regards
>>
>> Ed Willink
>>
>>
>> On 10/04/2014 14:17, Olivier Labrosse wrote:
>> > Thank you Ed. Please see comments below.
>> >
>> > Ed Merks wrote on Thu, 10 April 2014 08:27
>> >> Olivier,
>> >>
>> >> Comments below.
>> >>
>> >> On 09/04/2014 10:02 PM, Olivier Labrosse wrote:
>> >> > Hi,
>> >> >
>> >> > I have an ecore where a root "foo" package is empty except for a
>> >> few > sub-packages.
>> >> Subpackages are evil.
>> >> > One of the sub-packages, "bar", defines an EClass, "BarItem",
>> with >> an > EAnnotation. If the EAnnotation's source is "foobar"
>> and its > >> references point to the BazItem EClass in another
>> sub-package called >> > baz, BarPackageImpl will contain the
>> following method:
>> >> >
>> >> >
>> >> > protected void createFoobarAnnotations() {
>> >> > String source = "foobar"; //$NON-NLS-1$
>> >> > addAnnotation
>> >> > (barItemEClass, source, new String[] {
>> >> > },
>> >> > new URI[] {
>> >> >
>> URI.createURI(FooPackage.eNS_URI).appendFragment("//baz/BazItem") >
>> >> //$NON-NLS-1$
>> >> > });
>> >> > }
>> >> >
>> >> >
>> >> > The problem is that FooPackage (the root package) is not
>> generated, >> > seemingly due to being empty.
>> >> Yes. Does it generate something that fails to compile?
>> >
>> > Sorry I wasn't more precise. FooPackage.eNS_URI is the problem,
>> since > FooPackage doesn't exist. Indeed, it fails to compile.
>> >
>> >
>> > Quote:
>> >> > Am I doing something wrong, or should the generator either
>> inline >> the > URI string or create the root package classes even
>> though it is >> empty?
>> >> It should use the package that contains the BazItem EClass. If >>
>> that's not the case, please open a bugzilla (and be reminded that >>
>> subpackages are evil because there's always yet another corner case
>> >> that some tool won't handle well).
>> >
>> > Will do. Thanks again!
>
>
|
|
|
| Re: [EMF] EAnnotation references in sub-packages of empty package [message #1291016 is a reply to message #1290970] |
Thu, 10 April 2014 16:38 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Christian
Sorry, I forget. The scars still ache and so remind me not to do it. Of
course sometimes the diagnosis/memory is at fault.
I'm sure GenModel hates a null name becuause of course a null name would
be an invalid Java identifier. For the last few (? five) years genmodel
has had its own load-time validation so today's EMF users are spared all
the NPE excitement we used to enjoy.
The OCL Pivot performs Complete OCL package merge by nsURI collision
with a fall-back to name collision. Some of my problems are no doubt
self-inflicted.
Regards
Ed Willink
On 10/04/2014 16:46, Christian W. Damus wrote:
> Hi, Ed,
>
> Demand-created packages (for unrecognized content using EMF's XML
> AnyTypes) always have null names, though they generally have
> nsPrefixes (in qualified XML content). Which tools don't work with
> null package names?
>
> Cheers,
>
> Christian
>
>
> On 2014-04-10 13:45:21 +0000, Ed Willink said:
>
>> Hi
>>
>> EMF (and other tools) really hate EPackages with null nsURIs or null
>> names and sometimes even null nsPrefixes.
>>
>> GIT\org.eclipse.ocl\plugins\org.eclipse.ocl\model\OCL.ecore
>>
>> is almost what you describe and has been working for years.
>>
>> Regards
>>
>> Ed Willink
>>
>>
>> On 10/04/2014 14:17, Olivier Labrosse wrote:
>>> Thank you Ed. Please see comments below.
>>>
>>> Ed Merks wrote on Thu, 10 April 2014 08:27
>>>> Olivier,
>>>>
>>>> Comments below.
>>>>
>>>> On 09/04/2014 10:02 PM, Olivier Labrosse wrote:
>>>>> Hi,
>>>>>
>>>>> I have an ecore where a root "foo" package is empty except for a
>>>> few > sub-packages.
>>>> Subpackages are evil.
>>>>> One of the sub-packages, "bar", defines an EClass, "BarItem", with
>>>> an > EAnnotation. If the EAnnotation's source is "foobar" and its
>>>> > references point to the BazItem EClass in another sub-package called
>>>>> baz, BarPackageImpl will contain the following method:
>>>>>
>>>>>
>>>>> protected void createFoobarAnnotations() {
>>>>> String source = "foobar"; //$NON-NLS-1$
>>>>> addAnnotation
>>>>> (barItemEClass, source, new String[] {
>>>>> },
>>>>> new URI[] {
>>>>> URI.createURI(FooPackage.eNS_URI).appendFragment("//baz/BazItem") >
>>>> //$NON-NLS-1$
>>>>> });
>>>>> }
>>>>>
>>>>>
>>>>> The problem is that FooPackage (the root package) is not
>>>>> generated, seemingly due to being empty.
>>>> Yes. Does it generate something that fails to compile?
>>>
>>> Sorry I wasn't more precise. FooPackage.eNS_URI is the problem,
>>> since FooPackage doesn't exist. Indeed, it fails to compile.
>>>
>>>
>>> Quote:
>>>>> Am I doing something wrong, or should the generator either inline
>>>> the > URI string or create the root package classes even though it
>>>> is empty?
>>>> It should use the package that contains the BazItem EClass. If
>>>> that's not the case, please open a bugzilla (and be reminded that
>>>> subpackages are evil because there's always yet another corner case
>>>> that some tool won't handle well).
>>>
>>> Will do. Thanks again!
>
>
|
|
|
| Re: [EMF] EAnnotation references in sub-packages of empty package [message #1291029 is a reply to message #1291007] |
Thu, 10 April 2014 16:54 |
Olivier Labrosse
Messages: 49
Registered: November 2011 |
Member |
|
|
Sorry for the confusion. I did say the problem was due to the fact that the base xxxPackageImpl wasn't generated. If it were generated, the EAnnotation code would work just fine. For the time being, I'll simply use the sub-packages' eNS_URI.
I looked at some of your bugs, 411945 and 424893, and I can't say for sure whether the latter really covers this problem specifically. I'll post my own bug, and if it's really deemed a duplicate by the contributors, they can maybe describe the relationship.
Regards,
-Olivier
Ed Willink wrote on Thu, 10 April 2014 12:29Hi
I'm confused. Your original report was about eNS_URI NPEs, hence the
recommendation about non null content.
Now I think you are commenting on inadequate EAnnotations for which I
have raised a couple of EMF bugs over the last couple of releases; the
first generated bad code for nested package annotations and was fixed.
The second generated inadequate code and was WONTFIXed, which is a
problem for those wanting to avoid run-time loading. So it awaits a user
contribution of the fix.
Regards
Ed Willink
On 10/04/2014 17:12, Olivier Labrosse wrote:
> Hi Ed W.,
>
> Thanks for the reply. I took a look and the EAnnotation references in
> OCL.ecore are under "contents" nodes that aren't output to the
> generated TypesPackageImpl, hence why OCL wouldn't share my problem.
>
> One thing I did find in OCL.ecore that I thought might make a
> difference is the nsPrefixes. Mine didn't contain the base package
> nsPrefix like OCL's do. But after adding that base package nsPrefix
> and generating the code, nothing changed.
>
> Note that all my packages, including the base one, have nsURIs, names
> and nsPrefixes.
>
> Also note that the reason I'm using such EAnnotations is to define, in
> the meta-model, default model configurations by interface (i.e. EClass
> super-type). Maybe there's a better way to deal with this that I
> haven't considered yet? All I know is that, by my understanding, this
> should work.
>
> Thanks again!
>
> -Olivier
> Ed Willink wrote on Thu, 10 April 2014 09:45
>> Hi
>>
>> EMF (and other tools) really hate EPackages with null nsURIs or null
>> names and sometimes even null nsPrefixes.
>>
>> GIT\org.eclipse.ocl\plugins\org.eclipse.ocl\model\OCL.ecore
>>
>> is almost what you describe and has been working for years.
>>
>> Regards
>>
>> Ed Willink
>>
>>
>> On 10/04/2014 14:17, Olivier Labrosse wrote:
>> > Thank you Ed. Please see comments below.
>> >
>> > Ed Merks wrote on Thu, 10 April 2014 08:27
>> >> Olivier,
>> >>
>> >> Comments below.
>> >>
>> >> On 09/04/2014 10:02 PM, Olivier Labrosse wrote:
>> >> > Hi,
>> >> >
>> >> > I have an ecore where a root "foo" package is empty except for a
>> >> few > sub-packages.
>> >> Subpackages are evil.
>> >> > One of the sub-packages, "bar", defines an EClass, "BarItem",
>> with >> an > EAnnotation. If the EAnnotation's source is "foobar"
>> and its > >> references point to the BazItem EClass in another
>> sub-package called >> > baz, BarPackageImpl will contain the
>> following method:
>> >> >
>> >> >
>> >> > protected void createFoobarAnnotations() {
>> >> > String source = "foobar"; //$NON-NLS-1$
>> >> > addAnnotation
>> >> > (barItemEClass, source, new String[] {
>> >> > },
>> >> > new URI[] {
>> >> >
>> URI.createURI(FooPackage.eNS_URI).appendFragment("//baz/BazItem") >
>> >> //$NON-NLS-1$
>> >> > });
>> >> > }
>> >> >
>> >> >
>> >> > The problem is that FooPackage (the root package) is not
>> generated, >> > seemingly due to being empty.
>> >> Yes. Does it generate something that fails to compile?
>> >
>> > Sorry I wasn't more precise. FooPackage.eNS_URI is the problem,
>> since > FooPackage doesn't exist. Indeed, it fails to compile.
>> >
>> >
>> > Quote:
>> >> > Am I doing something wrong, or should the generator either
>> inline >> the > URI string or create the root package classes even
>> though it is >> empty?
>> >> It should use the package that contains the BazItem EClass. If >>
>> that's not the case, please open a bugzilla (and be reminded that >>
>> subpackages are evil because there's always yet another corner case
>> >> that some tool won't handle well).
>> >
>> > Will do. Thanks again!
>
>
|
|
| |
Goto Forum:
Current Time: Sat Apr 20 01:10:31 GMT 2024
Powered by FUDForum. Page generated in 0.03729 seconds |
] 
Search
Help
Register
Login
Home
