Home » Modeling » TMF (Xtext) » Re: Validation produces Duplicate EModelElement without reason
| |
| Re: Validation produces Duplicate EModelElement without reason [message #554509 is a reply to message #554479] |
Mon, 23 August 2010 12:37   |
 Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
On 23.08.10 13.01, Andy Carpenter wrote:
>
> 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.
Thanks, that's useful to avoid foo=bar details.
> I believe that the Xtext installation includes a plugin
> that treats an .ecore resource as a flat namespace.
That doesn't seem good. Can someone confirm this? What's strange in my
case is that Xtext seems to contribute validation participant, outside
an Xtext context.
> 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.
Thus avoiding validation of an Ecore model? Maybe a solution for the
problem of creating a genmodel, but I need an .ecore file (XMI
serialization) for other purposes, that must validate.
Hallvard
>> 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 #554522 is a reply to message #554479] |
Mon, 23 August 2010 13:25 |
Ed Merks
Messages: 33133
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 #554561 is a reply to message #554557] |
Mon, 23 August 2010 14:34 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
On 23.08.10 16.14, Sven Efftinge wrote:
> Am 8/23/10 4:03 PM, schrieb Hallvard Trætteberg:
>> On 23.08.10 15.55, Sven Efftinge wrote:
>>> Am 8/23/10 2:37 PM, schrieb Hallvard Trætteberg:
>>>>> I believe that the Xtext installation includes a plugin
>>>>> that treats an .ecore resource as a flat namespace.
>>>>
>>>> That doesn't seem good. Can someone confirm this? What's strange in my
>>>> case is that Xtext seems to contribute validation participant, outside
>>>> an Xtext context.
>>>
>>> Don't think so. Maybe you have installed an Xtext editor for *.ecore
>>> files? The NamesAreUniqueValidator is added by default and would be
>>> active if not removed explicitly.
>>
>> Emfatic (emf files) is an Xtext editor for ecore models residing in emf
>> files, but I didn't expect it to 1) validate ecore models with a
>> NamesAreUniqueValidator or 2) contribute a validator that is used for
>> ecore models loaded from ecore files.
>>
>> Hallvard
>
> AFAIK Emfatic is not based on Xtext.
Sorry, I incorrectly assumed it had been reimplemented as such, since
the use of the emfatic editor seemed to trigger Xtext somehow. Anyway,
the model validates correctly in the emfatic editor, so I don't think it
is faulty. It's still strange that the validation problem consistently
starts after trying to convert an ecore file to an emfatic file.
> Maybe the OCL in Xtext editor from (OCL examples) registeres the validator?
How is this done? In code? In a Guice module class? Using plugin.xml? Is
there a method I can set a breakpoint in, to see where this might happen?
Hallvard
|
|
| |
| Re: Validation produces Duplicate EModelElement without reason [message #554570 is a reply to message #554566] |
Mon, 23 August 2010 15:03 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
On 23.08.10 16.47, Sven Efftinge wrote:
> Am 8/23/10 4:34 PM, schrieb Hallvard Trætteberg:
>>> Maybe the OCL in Xtext editor from (OCL examples) registeres the
>>> validator?
>>
>> How is this done? In code? In a Guice module class? Using plugin.xml? Is
>> there a method I can set a breakpoint in, to see where this might happen?
>
> It is usually configured using the ComposedChecks annotation, which is
> set to a generated class called Abstract<LanguageName>JavaValidator
>
> You could set a breakpoint in
>
> org.eclipse.xtext.validation.AbstractDeclarativeValidator.co llectMethods(AbstractDeclarativeValidator,
> Class<? extends AbstractDeclarativeValidator>, Collection<Class<?>>,
> Collection<MethodWrapper>)
The class EmfaticJavaValidator's collectMethods method is called, and it
seems to register org.eclipse.xtext.validation.NamesAreUniqueValidator
method. The strange thing is that the emf (i.e. emfatic) file validates
correctly, but the ecore file (e.g. using the ecore editor) does not
validate any more, after the emf editor has been activated.
For what kind of object is a validator registered? A package? EClass?
File extension?
Hallvard
|
|
| |
| Re: Validation produces Duplicate EModelElement without reason [message #554636 is a reply to message #554570] |
Mon, 23 August 2010 19:09 |
Sven Efftinge
Messages: 1823
Registered: July 2009 |
Senior Member |
|
|
Am 8/23/10 5:03 PM, schrieb Hallvard Trætteberg:
> On 23.08.10 16.47, Sven Efftinge wrote:
>> Am 8/23/10 4:34 PM, schrieb Hallvard Trætteberg:
>>>> Maybe the OCL in Xtext editor from (OCL examples) registeres the
>>>> validator?
>>>
>>> How is this done? In code? In a Guice module class? Using plugin.xml? Is
>>> there a method I can set a breakpoint in, to see where this might
>>> happen?
>>
>> It is usually configured using the ComposedChecks annotation, which is
>> set to a generated class called Abstract<LanguageName>JavaValidator
>>
>> You could set a breakpoint in
>>
>> org.eclipse.xtext.validation.AbstractDeclarativeValidator.co llectMethods(AbstractDeclarativeValidator,
>>
>> Class<? extends AbstractDeclarativeValidator>, Collection<Class<?>>,
>> Collection<MethodWrapper>)
>
> The class EmfaticJavaValidator's collectMethods method is called, and it
> seems to register org.eclipse.xtext.validation.NamesAreUniqueValidator
> method. The strange thing is that the emf (i.e. emfatic) file validates
> correctly, but the ecore file (e.g. using the ecore editor) does not
> validate any more, after the emf editor has been activated.
>
> For what kind of object is a validator registered? A package? EClass?
> File extension?
It is registered per EPackage.
See org.eclipse.xtext.validation.EValidatorRegistrar as well as
org.eclipse.emf.ecore.EValidator.Registry.
It seems that some Xtext language you use registers a
NamesAreUniqueValidator for the EcorePackage.
Sven
--
--
Need professional support for Xtext or other Eclipse Modeling technologies?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : http://blog.efftinge.de
|
|
| |
| Re: Validation produces Duplicate EModelElement without reason [message #554662 is a reply to message #554636] |
Mon, 23 August 2010 22:35 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
On 23.08.10 21.09, Sven Efftinge wrote:
> It is registered per EPackage.
> See org.eclipse.xtext.validation.EValidatorRegistrar as well as
> org.eclipse.emf.ecore.EValidator.Registry.
>
> It seems that some Xtext language you use registers a
> NamesAreUniqueValidator for the EcorePackage.
With a breakpoint in org.eclipse.xtext.validation.EValidatorRegistrar's
register method I see that the class
uk.ac.man.cs.mdsd.emfatic.EmfaticRuntimeModule eventually registers an
EmfaticJavaValidator for EcorePackageImpl. This object in turn creates a
NamesAreUniqueValidator which is used for validating my ecore model.
First, I validate the ecore model loaded from an emf file (in the
emfatic editor), i.e. as part of an EmfaticResource. It provides a set
of descriptions, which contain the following (shortened list of)
qualified names: [Team, Team.name, Team.players, Player, Player.name,
....]. All these are unique, so my model is valid. BTW, the
IResourceDescription.Manager is an EmfaticResourceDescriptionManager.
However, when the same model is validated when loaded from an ecore file
(in the ecore editor), the set of qualified names are the following
(again shortened): [football, Team, name, players, Player, name, ...].
The names are no longer properly qualified and hence there are
duplicates! This time the IResourceDescription.Manager is an
EcoreResourceDescriptionManager.
It seems strange that the descriptions for the model objects, as
provided by EcoreResourceDescriptionManager, do not contain qualified
names. But it may also be that it is not meant to be used for validating
an ecore model.
Any suggestions?
Hallvard
|
|
|
| Re: Validation produces Duplicate EModelElement without reason [message #554696 is a reply to message #554662] |
Tue, 24 August 2010 06:31 |
Sven Efftinge
Messages: 1823
Registered: July 2009 |
Senior Member |
|
|
Am 8/24/10 12:35 AM, schrieb Hallvard Trætteberg:
> On 23.08.10 21.09, Sven Efftinge wrote:
>> It is registered per EPackage.
>> See org.eclipse.xtext.validation.EValidatorRegistrar as well as
>> org.eclipse.emf.ecore.EValidator.Registry.
>>
>> It seems that some Xtext language you use registers a
>> NamesAreUniqueValidator for the EcorePackage.
>
> With a breakpoint in org.eclipse.xtext.validation.EValidatorRegistrar's
> register method I see that the class
> uk.ac.man.cs.mdsd.emfatic.EmfaticRuntimeModule eventually registers an
> EmfaticJavaValidator for EcorePackageImpl. This object in turn creates a
> NamesAreUniqueValidator which is used for validating my ecore model.
So that's the problem.
Emfatic shouldn't register a validator, as ecore brings its own validator.
>
> First, I validate the ecore model loaded from an emf file (in the
> emfatic editor), i.e. as part of an EmfaticResource. It provides a set
> of descriptions, which contain the following (shortened list of)
> qualified names: [Team, Team.name, Team.players, Player, Player.name,
> ...]. All these are unique, so my model is valid. BTW, the
> IResourceDescription.Manager is an EmfaticResourceDescriptionManager.
An IResourceDescription.Manager is registered for the file extension.
By default it computes qualified names with '.' as delimiter char.
>
> However, when the same model is validated when loaded from an ecore file
> (in the ecore editor), the set of qualified names are the following
> (again shortened): [football, Team, name, players, Player, name, ...].
> The names are no longer properly qualified and hence there are
> duplicates! This time the IResourceDescription.Manager is an
> EcoreResourceDescriptionManager.
Xtext comes with a ResourceDescriptionManger for Ecore (registered for
*.ecore). As the NamesAreUniqueValiator is registered for the
EcorePackage it is used in any scenario where an instance of ecore is
validated.
We should (and will) fix the EcoreResourceDescriptionManager to export
qualified names. But the core problem is, that an additional validator
is registered for EcorePackage.
>
> It seems strange that the descriptions for the model objects, as
> provided by EcoreResourceDescriptionManager, do not contain qualified
> names. But it may also be that it is not meant to be used for validating
> an ecore model.
>
> Any suggestions?
Remove the validator by overriding the corresponding binding method in
the guice module and return 'null'.
Sven
--
--
Need professional support for Xtext or other Eclipse Modeling technologies?
Go to: http://xtext.itemis.com
Twitter : @svenefftinge
Blog : http://blog.efftinge.de
|
|
|
| Re: Validation produces Duplicate EModelElement without reason [message #554703 is a reply to message #554696] |
Tue, 24 August 2010 07:00 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
First of all, thanks for the help, Sven! I wouldn't have known where to
look without it!
On 24.08.10 08.31, Sven Efftinge wrote:
> Am 8/24/10 12:35 AM, schrieb Hallvard Trætteberg:
>
> So that's the problem.
> Emfatic shouldn't register a validator, as ecore brings its own validator.
Yes, there shouldn't be any reason to add/override rules of Ecore's own.
> We should (and will) fix the EcoreResourceDescriptionManager to export
> qualified names. But the core problem is, that an additional validator
> is registered for EcorePackage.
I think both fixes would solve the problem. Emfatic's validation would
be correct if the exported names were qualified. But I agree, the
"extra" validator is totally unnecessary.
> Remove the validator by overriding the corresponding binding method in
> the guice module and return 'null'.
I'm not sure who "owns" emfatic, but Andy provided my current
installation, so hopefully he can and will do it. I'd be happy to do it
myself if I had the rights. Another aspect that I could help with is the
formatter/serializer. When exporting the ecore to emfatic, linebreaks
are inserted in the wrong places.
Hallvard
|
|
| | | | | | | |
| Re: Validation produces Duplicate EModelElement without reason [message #555057 is a reply to message #555012] |
Wed, 25 August 2010 09:53 |
Andy Carpenter
Messages: 145
Registered: July 2009 |
Senior Member |
|
|
Hi Sven,
>>> Maybe you should start by adding your code to a bugzilla, so we can
>>> discuss whether it is a better basis for the great shiny textual Ecore
>>> editor of our future :-)
>>
>> Added as https://bugs.eclipse.org/bugs/show_bug.cgi?id=323501
>
> Thanks. Do you have the time to maintain and further develop it under
> Eclipse EMFT? If yes I'ld like to propose you as a committer.
Yes, I have the time to do this (I use it in my teaching
and have an interest in keeping it running).
> I'm currently running a research project (called Xbase) where we develop
> a base language in Xtext which is meant to be reused and extended by
> other languages (I'll blog about it within the next days). One language
> we want to do as apart of the research project is a textual language for
> Ecore which supports expressing behavior in operations and derived
> features (i.e reusing Xbase). We will definitely build that language and
> would like to host it under EMFatic as well (we don't neccessarily need
> to, but I think it belongs there).
>
> But I also don't want to hinder anyone from going into different
> directions (like what Ed Willink did with the OCL in Ecore). That's all
> interesting and valuable.
>
> I'm just saying this because we might end up with two different
> languages. Maybe it will be like in rest of modeling one OMG standards
> based (i.e. using OCL) and one which is not...
>
> Thoughts?
In the longer term this sounds interesting. My interest is in a language
in which models that include invariants can be expressed and from
which implementations that include invariant checking can be
generated. As part of this, I want checking of the invariant expressions
at model definition time, rather than runtime. At the moment,
Emfatic with OCL delegates does this for me. However, if another
language comes along that has good tooling and support, then
I might well switch.
Andy.
|
|
|
| Re: Validation produces Duplicate EModelElement without reason [message #555060 is a reply to message #555057] |
Wed, 25 August 2010 10:56 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
On 25.08.10 11.53, Andy Carpenter wrote:
>> I'm just saying this because we might end up with two different
>> languages. Maybe it will be like in rest of modeling one OMG standards
>> based (i.e. using OCL) and one which is not...
>>
>> Thoughts?
>
> In the longer term this sounds interesting. My interest is in a language
> in which models that include invariants can be expressed and from
> which implementations that include invariant checking can be
> generated. As part of this, I want checking of the invariant expressions
> at model definition time, rather than runtime. At the moment,
> Emfatic with OCL delegates does this for me. However, if another
> language comes along that has good tooling and support, then
> I might well switch.
I have a similar interest (models with invariants etc), and would like
to help in making emfatic better for this (and as a general ecore
editor). I think it is important to support multiple languages, a bit
like ecore does with its delegates. There are OCL delegates, I have
javascript delegates implemented, the Epsilon people might want to
support EOL delegates etc. I understand it is difficult to support
mixins in Xtext, but providing a base that specific languages may extend
would be very nice.
Hallvard
|
|
|
Goto Forum:
Current Time: Tue Apr 16 14:22:22 GMT 2024
Powered by FUDForum. Page generated in 0.52256 seconds |
] 
Search
Help
Register
Login
Home
