Eclipse Community Forums: EMF » Genmodel warnings with 2019-06

Home » Modeling » EMF » Genmodel warnings with 2019-06

Genmodel warnings with 2019-06 [message #1814950]

Mon, 23 September 2019 07:15

Eclipse User

We recently updated from Oxygen.2 (finally) and now I'm getting some warnings when opening my genmodel.

I couldn't get any markers, validating the ecore and genmodel reported no error or warnings and couldn't figure out what those referred to, until I did a text search on "documentedName" that was part of some warnings. I found out it came from a referenced model "viewpoints" from Sirius.

Even when opening the viewpoints genmodel, I get the warnings, but validating that genmodel reports no errors/warnings.

What are these and how can I handle this, other than ignoring or removing from source ? And also why is that being reported at the level of my genmodel?

Thanks
Alain

Attachment: gen warnings.PNG
(Size: 41.08KB, Downloaded 101 times)
Attachment: viewpoints.PNG
(Size: 33.03KB, Downloaded 104 times)

[Updated on: Mon, 23 September 2019 07:16] by Moderator

Re: Genmodel warnings with 2019-06 [message #1814951 is a reply to message #1814950]

Mon, 23 September 2019 07:27

Eclipse User

GenModel annotations are now validated based on how they are actually processed by the GenModel. Anything that will not be processed (i.e., will not be mapped to something in the GenMode or its children) will get such a warning. These warnings all look to be of this form.

I don't know what Sirius is doing with these annotations, nor why they are using the GenModel's nsURI as source for that purpose; you'll have to ask them the reason for this approach. In any case, these are "just" warnings, and they are not in your model, so you won't be able to fix or avoid them. That's something Sirius will need to do.

Re: Genmodel warnings with 2019-06 [message #1814953 is a reply to message #1814951]

Mon, 23 September 2019 07:33

Eclipse User

Thanks for the quick reply Ed. This is a very old version of Sirius model that we have adapted lightly, so will adapt a bit more :)

Re: Genmodel warnings with 2019-06 [message #1814974 is a reply to message #1814953]

Mon, 23 September 2019 11:19

Eclipse User

Hi,

From what I understand, we (in Sirius) have "always" had these kinds of entries in our ecore models, but they were never copied into the genmodel until recently (https://git.eclipse.org/r/c/144333/ from last June) when we reloaded the genmodels & regen of our code using EMF 2.18.

I don't know what was the reasoning for reusing this nsURI for our own keys at the time (it's probably more than 10 years old). Maybe it was a bad idea but it did not cause any visible ill effect until the regen using EMF 2.18.

Alain, can you open a ticket on Sirius ? I'm not sure if/when we'll be able to look at this, but at least it will be tracked.

Regards,
Pierre-Charles

Re: Genmodel warnings with 2019-06 [message #1814981 is a reply to message #1814974]

Mon, 23 September 2019 12:22

Eclipse User

It's no big deal, given they are just warnings on the Ecore model (basically all of them saying, the GenModel will ignore these annotations/details). Note too that it's not the generator that's complaining, it's the extensible Ecore annotation processor, specifically org.eclipse.emf.codegen.ecore.genmodel.util.GenModelAnnotatonValidator in this case, which was added for EMF 2.14 as part of the 2018-06 release which is doing the complaining.

Re: Genmodel warnings with 2019-06 [message #1814985 is a reply to message #1814974]

Mon, 23 September 2019 13:04

Eclipse User

I will, but here we have a forked version of it, so we will remove at our end as well for now.

Merci,
Alain

Re: Genmodel warnings with 2019-06 [message #1814987 is a reply to message #1814951]

Mon, 23 September 2019 13:50

Eclipse User

Ed,

I've encountered a pretty significant regression and not sure if it's derived from this, but I have some EAnnotation with reference. See ecore snip image.

As you can see this is on a sub package. After debugging and running the code on a version prior to my regeneration I found out that the root package impl has changed as shown in package diff image.

So then when it attempts to resolve the proxy in EcoreUtils (still using 2.13.0) it gets the package correctly, but the resource is the root package, but the fragment is relative to the sub package now instead of the root package.

Is there a new setting to change or something is going wrong or ???

Thanks
Alain

Attachment: ecore snip.PNG
(Size: 13.11KB, Downloaded 95 times)
Attachment: package diff.PNG
(Size: 6.77KB, Downloaded 112 times)
Attachment: ecoreutil snip.PNG
(Size: 11.62KB, Downloaded 91 times)

Re: Genmodel warnings with 2019-06 [message #1814988 is a reply to message #1814987]

Mon, 23 September 2019 14:23

Eclipse User

The annotation processing is just used for editing and validation; that has no impact on code generation.

You're showing pictures of serialization differences and those differences are off course reflected in the generated package. But I have no idea of the structure of your resources so I cannot comment if there is something wrong with the serialization. If there is a specific problem that you want me to investigate I will need a Bugzilla report with complete self-contained example that reproduces the problem.

Re: Genmodel warnings with 2019-06 [message #1814991 is a reply to message #1814988]

Mon, 23 September 2019 14:41

Eclipse User

Ed,

Thanks for reaching out.

I am generating with the same ecore and genmodel as before, but now running with 2019-06.

I'm not sure I follow "You're showing pictures of serialization differences and those differences are off course reflected in the generated package". I'm showing a single unchanged ecore source resulting in differences in the generated package.

So what I'm showing is first a snippet from the ecore showing how the EAnnotation looks like and in package diff how it got generated differently and finally what ends up being the issue in resolving such a proxy.

And my question is, is this normal for the generation to have changed in a such a breaking way or is there now an additional setting or it is a bug?

Thanks,
Alain

Re: Genmodel warnings with 2019-06 [message #1814997 is a reply to message #1814988]

Mon, 23 September 2019 16:58

Eclipse User

Ed,

I looked at the code changes from 2017 onward and zoned in the change on 2018-11-27 labeled [432544] EAnnotation references in nested packages use inexistent base xxxPackageImpl and finally ran a debugging session and it is the culprit.

Ironically, this issue was opened many years ago by a member of my team. The problem is that now the resolution gets "rooted" (the URI.createURI part) on the parent package instead of the root package, but the proxy resolution in EcoreUtil#resolve(EObject proxy, ResourceSet resourceSet) is not adapted to it. On line 213, it gets the resource and might have to go through parents to find it, but then it doesn't adjust the fragment path to account for those navigate parents.

Honestly issue 432544 is not critical but this one is totally breaking. What are the next steps? I surely can open a bugzilla about it but changing the codegen locally is a mess, I might more consider running a locally modified EcoreUtil to re-add the naviaged fragment paths.

Cheers,
Alain

Re: Genmodel warnings with 2019-06 [message #1815000 is a reply to message #1814997]

Tue, 24 September 2019 00:01

Eclipse User

I can only fix a problem that I can reproduce. As I've always said, subpackages are evil and lead to problems.

It appears that 432544 was fixed without an attachment with a test case so I would have had to make up one myself based on the description. Apparently what I made up is not reflective of your actual problem. Further more, when the problem was "fixed," the reporter of the problem never bothered to look at the result, at least until you did 3 releases later.

So if you want me to look at this problem again, you'll need to open a Bugzilla with an attachment of something that reproduces your exact problem. Because the picture I see here

https://www.eclipse.org/forums/index.php?t=getfile&id=36373&

is exactly what I would expect if "motivation" is a blank root package, i.e, one without classifiers that doesn't actually generate a corresponding EPackage in the generated code. But now of course it's not clear to me at all if "motivation" really is a blank root package or not.

Finally, take note that there would not be any "corresponding" changes in the proxy resolution code; that code is generic and would not contain specialized behavior for any model, not even for Ecore. It all boils down too exactly what resources actually exist for the generated model? Perhaps you have multiple root resources because you've put a useless "blank" package in the root of your original single resource and are ultimately trying to use cross references between it's subpackages. But that's not the original test case that I had to synthesize. And that's why I will not look at this problem without an actual test case this time.

You might avoid this problem by splitting your model into multiple *.ecore resources and specifying your *.genmodel to compose those rather than doing the composition via a blank (pointless and error prone) root package, or you might add a dummy classifier (EDataType) to your blank root package so that it's not a blank root package (generating pointless and useless code). Or you open a Bugzilla and actually test the result, with the underlying assumption that I will actually fix it for free in a timely manner. :-P

Re: Genmodel warnings with 2019-06 [message #1815003 is a reply to message #1815000]

Tue, 24 September 2019 01:06

Eclipse User

Hi

The URIs of nested packages do change between dynamic and static versions. e.g. the dynamic path A::B::C becomes the static path C when C.java is produced and EcoreUtil finds no reason to mention A::B::.

This is not normally a problem until you mix usage of dynamic and static model access as model transformation tends to do.

IIRC I was trying to improve the fix this in the OCL ProjectMap a few months ago, found it hard and got distracted. It's still on my bug fix in progress stack.

Regards

Ed Willink

Previous Topic:	Overriding Feature lowerBound
Next Topic:	Hook to prevent command execution

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 23 16:06:57 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter