Genmodel warnings with 2019-06 [message #1814950] |
Mon, 23 September 2019 11:15 |
Alain Picard Messages: 266 Registered: July 2009 |
Senior Member |
|
|
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
[Updated on: Mon, 23 September 2019 11:16] Report message to a moderator
|
|
|
|
|
Re: Genmodel warnings with 2019-06 [message #1814974 is a reply to message #1814953] |
Mon, 23 September 2019 15:19 |
|
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
Pierre-Charles David - Obeo
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius
|
|
|
|
|
|
|
|
|
Re: Genmodel warnings with 2019-06 [message #1815000 is a reply to message #1814997] |
Tue, 24 September 2019 04:01 |
Ed Merks Messages: 33140 Registered: July 2009 |
Senior Member |
|
|
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
Powered by
FUDForum. Page generated in 0.03673 seconds