Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Validation produces Duplicate EModelElement without reason
Validation produces Duplicate EModelElement without reason [message #553636] Wed, 18 August 2010 08:34 Go to next message
Hallvard Traetteberg is currently offline Hallvard Traetteberg
Messages: 594
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 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26054
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
Re: Validation produces Duplicate EModelElement without reason [message #553835 is a reply to message #553714] Thu, 19 August 2010 06:45 Go to previous messageGo to next message
Hallvard Traetteberg is currently offline Hallvard Traetteberg
Messages: 594
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 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26054
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
Re: Validation produces Duplicate EModelElement without reason [message #554176 is a reply to message #553966] Fri, 20 August 2010 12:37 Go to previous messageGo to next message
Hallvard Traetteberg is currently offline Hallvard Traetteberg
Messages: 594
Registered: July 2009
Location: Trondheim, Norway
Senior Member
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 #554480 is a reply to message #554176] Mon, 23 August 2010 11:01 Go to previous messageGo to next message
Andy Carpenter is currently offline Andy Carpenter
Messages: 145
Registered: July 2009
Senior Member
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 #554519 is a reply to message #554480] Mon, 23 August 2010 13:25 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26054
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
>
Re: Validation produces Duplicate EModelElement without reason [message #554546 is a reply to message #554519] Mon, 23 August 2010 13:46 Go to previous messageGo to next message
Hallvard Traetteberg is currently offline Hallvard Traetteberg
Messages: 594
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 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26054
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
>>>
>
Re: Validation produces Duplicate EModelElement without reason [message #554554 is a reply to message #554547] Mon, 23 August 2010 14:17 Go to previous messageGo to next message
Hallvard Traetteberg is currently offline Hallvard Traetteberg
Messages: 594
Registered: July 2009
Location: Trondheim, Norway
Senior Member
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. Is
this possible with the current registries and extension points?

Hallvard
Re: Validation produces Duplicate EModelElement without reason [message #554575 is a reply to message #554554] Mon, 23 August 2010 15:07 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26054
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
Previous Topic:EMF model live OCL constraints
Next Topic:Can EMF 2.6 live with Equinox 3.5?
Goto Forum:
  


Current Time: Fri Sep 19 18:09:39 GMT 2014

Powered by FUDForum. Page generated in 0.01970 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software