Home » Modeling » EMF » Validation produces Duplicate EModelElement without reason
Validation produces Duplicate EModelElement without reason [message #553636] |
Wed, 18 August 2010 08:34 |
Hallvard Traetteberg Messages: 673 Registered: July 2009 Location: Trondheim, Norway |
Senior Member |
|
|
Hi,
I was happily modelling football teams, players and matches, then all of
a sudden the model started producing 'Duplicate EModelElement'
validation errors. This happens both when I use the Validate action or
try to create or refresh the genmodel.
The EModelElements in question were EAttributes, EReferences and
EParameters, pairs of which had the same name, but different containers.
E.g. both Team and Player have a name attribute. As an experiment I
changed one of them to aName, and the corresponding validation error
went away. Clearly, this isn't a solution, so I renamed it back and the
error reappeared. Then I restarted Eclipse and voila, no validation
errors! This fortunately allowed me to refresh the genmodel, but
unfortunately the errors reappeared.
Is this a known issue? My installation is based on the modelling package
with some extra modelling goodies, including Epsilon.
Hallvard
|
|
|
Re: Validation produces Duplicate EModelElement without reason [message #553714 is a reply to message #553636] |
Wed, 18 August 2010 14:57 |
Ed Merks Messages: 33141 Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Comments below.
Hallvard Trætteberg wrote:
> Hi,
>
> I was happily modelling football teams, players and matches, then all
> of a sudden the model started producing 'Duplicate EModelElement'
> validation errors. This happens both when I use the Validate action or
> try to create or refresh the genmodel.
>
> The EModelElements in question were EAttributes, EReferences and
> EParameters, pairs of which had the same name, but different
> containers. E.g. both Team and Player have a name attribute. As an
> experiment I changed one of them to aName, and the corresponding
> validation error went away. Clearly, this isn't a solution, so I
> renamed it back and the error reappeared. Then I restarted Eclipse and
> voila, no validation errors! This fortunately allowed me to refresh
> the genmodel, but unfortunately the errors reappeared.
>
> Is this a known issue? My installation is based on the modelling
> package with some extra modelling goodies, including Epsilon.
Is it possible some class is inheriting from both other classes? The
union of all inherited features still needs to have unique names...
>
> Hallvard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: Validation produces Duplicate EModelElement without reason [message #553835 is a reply to message #553714] |
Thu, 19 August 2010 06:45 |
Hallvard Traetteberg Messages: 673 Registered: July 2009 Location: Trondheim, Norway |
Senior Member |
|
|
On 18.08.10 16.57, Ed Merks wrote:
> Hallvard,
>
> Comments below.
>
> Hallvard Trætteberg wrote:
>> Hi,
>>
>> I was happily modelling football teams, players and matches, then all
>> of a sudden the model started producing 'Duplicate EModelElement'
>> validation errors. This happens both when I use the Validate action or
>> try to create or refresh the genmodel.
....
>> Is this a known issue? My installation is based on the modelling
>> package with some extra modelling goodies, including Epsilon.
> Is it possible some class is inheriting from both other classes? The
> union of all inherited features still needs to have unique names...
I don't thing there's anything wrong with the model. After restarting it
validates. After a while it doesn't, without having touched anything
besides some annotations. Another restart, and it validates again.
In what places should I look for plugins/classes that may affect or
contribute the validation? Could it be due to having registered the same
EPackage twice or something?
Hallvard
|
|
|
Re: Validation produces Duplicate EModelElement without reason [message #553966 is a reply to message #553835] |
Thu, 19 August 2010 14:21 |
Ed Merks Messages: 33141 Registered: July 2009 |
Senior Member |
|
|
Hallvard,
I've never seen a case like that. It should only complain about
duplicates in the context of all the features of a given class in
EcoreValidator.validateEClass_UniqueFeatureNames. So if you can run
under debug control and check out what's happening there when the
problem arises, that will help...
Hallvard Trætteberg wrote:
> On 18.08.10 16.57, Ed Merks wrote:
>> Hallvard,
>>
>> Comments below.
>>
>> Hallvard Trætteberg wrote:
>>> Hi,
>>>
>>> I was happily modelling football teams, players and matches, then all
>>> of a sudden the model started producing 'Duplicate EModelElement'
>>> validation errors. This happens both when I use the Validate action or
>>> try to create or refresh the genmodel.
>
> ...
>
>>> Is this a known issue? My installation is based on the modelling
>>> package with some extra modelling goodies, including Epsilon.
>
>> Is it possible some class is inheriting from both other classes? The
>> union of all inherited features still needs to have unique names...
>
> I don't thing there's anything wrong with the model. After restarting
> it validates. After a while it doesn't, without having touched
> anything besides some annotations. Another restart, and it validates
> again.
>
> In what places should I look for plugins/classes that may affect or
> contribute the validation? Could it be due to having registered the
> same EPackage twice or something?
>
> Hallvard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
Re: Validation produces Duplicate EModelElement without reason [message #554519 is a reply to message #554480] |
Mon, 23 August 2010 13:25 |
Ed Merks Messages: 33141 Registered: July 2009 |
Senior Member |
|
|
Andy,
Yes, I don't see why both representations would be needed, except that
some of the tools, like the importers, support a fixed set of
extensions, *.ecore and *.emof, and should be extended. Does the
importer itself end up creating a *.ecore? Does it need to? I'd love
to see Emfatic more of a mainstream thing and to eliminate redundant
representations...
Andy Carpenter wrote:
> Hallvard,
>
> I've deployed a new version of the Emfatic software
> that will successfully serialize an Ecore model that contains
> annotations without details to the Emfatic format.
>
> I believe that the Xtext installation includes a plugin
> that treats an .ecore resource as a flat namespace.
>
> Having converted the Ecore model in xmi syntax to
> Emfatic syntax, the xmi serialisation is no longer required.
> The tooling includes a model importer that allows an Ecore
> model expressed in Emfatic syntax to be used to create
> an EMF Generator Model.
>
> Andy.
>
>
> "Hallvard Trætteberg" <hal@idi.ntnu.no> wrote in message
> news:4C6E7700.8030003@idi.ntnu.no...
>> On 19.08.10 16.21, Ed Merks wrote:
>>> Hallvard,
>>>
>>> I've never seen a case like that. It should only complain about
>>> duplicates in the context of all the features of a given class in
>>> EcoreValidator.validateEClass_UniqueFeatureNames. So if you can run
>>> under debug control and check out what's happening there when the
>>> problem arises, that will help...
>>
>> I've traced the problem to class
>> org.eclipse.xtext.validation.NamesAreUniqueValidator
>>
>> For some reason Xtext's validator for unique names within a resource
>> is triggered for this file. The following steps reproduced the problem:
>> - run the second Eclipse instance
>> - validate the ecore file and see that it validates
>> - try to convert ecore file to emfatic format, which produces errors
>> because some annotations don't have details (lower bound of details
>> feature is 1)
>> - validate the ecore file and see that it doesn't validate any more,
>> due to the above-mentioned validator
>>
>> Now what to do?
>>
>> Hallvard
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: Validation produces Duplicate EModelElement without reason [message #554546 is a reply to message #554519] |
Mon, 23 August 2010 13:46 |
Hallvard Traetteberg Messages: 673 Registered: July 2009 Location: Trondheim, Norway |
Senior Member |
|
|
I agree, Emfatic is a very handy representation. From a programming
point of view, we need a standard way of loading a data file for a model
independent of serialization format.
For most models, there can be generic and specific formats. E.g. for
ecore you have the generic xmi format (with ecore extension), the
specific emf(atic) format and the generic hutn format (specified OMG and
implemented by the Epsilon project). For a specific language the generic
ones (xmi and hutn) may both be used, as well as custom ones, based on
e.g. Xtext or EMFtext. It would be great to be able to ask for and load
a file for a specific model independent of format, using a simple API.
Hallvard
On 23.08.10 15.25, Ed Merks wrote:
> Andy,
>
> Yes, I don't see why both representations would be needed, except that
> some of the tools, like the importers, support a fixed set of
> extensions, *.ecore and *.emof, and should be extended. Does the
> importer itself end up creating a *.ecore? Does it need to? I'd love to
> see Emfatic more of a mainstream thing and to eliminate redundant
> representations...
>
>
> Andy Carpenter wrote:
>> Hallvard,
>>
>> I've deployed a new version of the Emfatic software
>> that will successfully serialize an Ecore model that contains
>> annotations without details to the Emfatic format.
>>
>> I believe that the Xtext installation includes a plugin
>> that treats an .ecore resource as a flat namespace.
>>
>> Having converted the Ecore model in xmi syntax to
>> Emfatic syntax, the xmi serialisation is no longer required.
>> The tooling includes a model importer that allows an Ecore
>> model expressed in Emfatic syntax to be used to create
>> an EMF Generator Model.
>>
>> Andy.
>>
>>
>> "Hallvard Trætteberg" <hal@idi.ntnu.no> wrote in message
>> news:4C6E7700.8030003@idi.ntnu.no...
>>> On 19.08.10 16.21, Ed Merks wrote:
>>>> Hallvard,
>>>>
>>>> I've never seen a case like that. It should only complain about
>>>> duplicates in the context of all the features of a given class in
>>>> EcoreValidator.validateEClass_UniqueFeatureNames. So if you can run
>>>> under debug control and check out what's happening there when the
>>>> problem arises, that will help...
>>>
>>> I've traced the problem to class
>>> org.eclipse.xtext.validation.NamesAreUniqueValidator
>>>
>>> For some reason Xtext's validator for unique names within a resource
>>> is triggered for this file. The following steps reproduced the problem:
>>> - run the second Eclipse instance
>>> - validate the ecore file and see that it validates
>>> - try to convert ecore file to emfatic format, which produces errors
>>> because some annotations don't have details (lower bound of details
>>> feature is 1)
>>> - validate the ecore file and see that it doesn't validate any more,
>>> due to the above-mentioned validator
>>>
>>> Now what to do?
>>>
>>> Hallvard
>>
|
|
|
Re: Validation produces Duplicate EModelElement without reason [message #554547 is a reply to message #554546] |
Mon, 23 August 2010 13:57 |
Ed Merks Messages: 33141 Registered: July 2009 |
Senior Member |
|
|
Hallvard,
ResourceSet.getResource should always load a resource regardless of
format, and I'd expect Resource.getContents will hold an EPackage
regardless of the specific representation. I.e., this should already be
pretty transparent...
Hallvard Trætteberg wrote:
> I agree, Emfatic is a very handy representation. From a programming
> point of view, we need a standard way of loading a data file for a
> model independent of serialization format.
>
> For most models, there can be generic and specific formats. E.g. for
> ecore you have the generic xmi format (with ecore extension), the
> specific emf(atic) format and the generic hutn format (specified OMG
> and implemented by the Epsilon project). For a specific language the
> generic ones (xmi and hutn) may both be used, as well as custom ones,
> based on e.g. Xtext or EMFtext. It would be great to be able to ask
> for and load a file for a specific model independent of format, using
> a simple API.
>
> Hallvard
>
> On 23.08.10 15.25, Ed Merks wrote:
>> Andy,
>>
>> Yes, I don't see why both representations would be needed, except that
>> some of the tools, like the importers, support a fixed set of
>> extensions, *.ecore and *.emof, and should be extended. Does the
>> importer itself end up creating a *.ecore? Does it need to? I'd love to
>> see Emfatic more of a mainstream thing and to eliminate redundant
>> representations...
>>
>>
>> Andy Carpenter wrote:
>>> Hallvard,
>>>
>>> I've deployed a new version of the Emfatic software
>>> that will successfully serialize an Ecore model that contains
>>> annotations without details to the Emfatic format.
>>>
>>> I believe that the Xtext installation includes a plugin
>>> that treats an .ecore resource as a flat namespace.
>>>
>>> Having converted the Ecore model in xmi syntax to
>>> Emfatic syntax, the xmi serialisation is no longer required.
>>> The tooling includes a model importer that allows an Ecore
>>> model expressed in Emfatic syntax to be used to create
>>> an EMF Generator Model.
>>>
>>> Andy.
>>>
>>>
>>> "Hallvard Trætteberg" <hal@idi.ntnu.no> wrote in message
>>> news:4C6E7700.8030003@idi.ntnu.no...
>>>> On 19.08.10 16.21, Ed Merks wrote:
>>>>> Hallvard,
>>>>>
>>>>> I've never seen a case like that. It should only complain about
>>>>> duplicates in the context of all the features of a given class in
>>>>> EcoreValidator.validateEClass_UniqueFeatureNames. So if you can run
>>>>> under debug control and check out what's happening there when the
>>>>> problem arises, that will help...
>>>>
>>>> I've traced the problem to class
>>>> org.eclipse.xtext.validation.NamesAreUniqueValidator
>>>>
>>>> For some reason Xtext's validator for unique names within a resource
>>>> is triggered for this file. The following steps reproduced the
>>>> problem:
>>>> - run the second Eclipse instance
>>>> - validate the ecore file and see that it validates
>>>> - try to convert ecore file to emfatic format, which produces errors
>>>> because some annotations don't have details (lower bound of details
>>>> feature is 1)
>>>> - validate the ecore file and see that it doesn't validate any more,
>>>> due to the above-mentioned validator
>>>>
>>>> Now what to do?
>>>>
>>>> Hallvard
>>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Re: Validation produces Duplicate EModelElement without reason [message #554575 is a reply to message #554554] |
Mon, 23 August 2010 15:07 |
Ed Merks Messages: 33141 Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Comments below.
Hallvard Trætteberg wrote:
> On 23.08.10 15.57, Ed Merks wrote:
>>
>> ResourceSet.getResource should always load a resource regardless of
>> format, and I'd expect Resource.getContents will hold an EPackage
>> regardless of the specific representation. I.e., this should already be
>> pretty transparent...
>
> I'm aware of getResource and the registries. But don't you either need
> to know the file extension or have a specific content type already
> defined? E.g. I would like to ask for a serialized ecore model (i.e.
> model with Ecore URI) with the name foo and get a list of foo.ecore,
> foo.emf, foo.hutn or foo.xmi for the ecore model, if all these exist.
You mean a mapping from names to their physical location? Or mapping
from nsURIs to their physical location?
> Is this possible with the current registries and extension points?
The latter is certainly possible with global and local package
registries and with URI mappings.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=220218 would help a lot.
The indexing project would help too...
>
> Hallvard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 22:26:57 GMT 2024
Powered by FUDForum. Page generated in 0.03853 seconds
|