Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Ecore definition and model instances in the same workbench
Ecore definition and model instances in the same workbench [message #986621] Wed, 21 November 2012 08:46 Go to next message
Eclipse User
Hello everybody,

is there a way to open a generic EMF editor to create and edit instances
(as XMI files) of an Ecore model which is developed in the same
workbench? And along the same line, is there a way to have such and XMI
file be validated against that .ecore? I think this is some kind of
chicken-and-egg issue. So I've been wondering if there is already
somewhere some magic kind of workspace/*.ecore <-> global EMF registry
syncer plugin?

The obvious workaround is of course to start a runtime workbench, but
that is a rather harsh setback for the development workflow.

Regards
Marius
Re: Ecore definition and model instances in the same workbench [message #986815 is a reply to message #986621] Wed, 21 November 2012 18:05 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26088
Registered: July 2009
Senior Member
Marius,

Comments below.

On 21/11/2012 9:46 AM, Marius Gröger wrote:
> Hello everybody,
>
> is there a way to open a generic EMF editor to create and edit instances
> (as XMI files) of an Ecore model which is developed in the same
> workbench?
Yes.
> And along the same line, is there a way to have such and XMI
> file be validated against that .ecore?
Yes.
> I think this is some kind of
> chicken-and-egg issue. So I've been wondering if there is already
> somewhere some magic kind of workspace/*.ecore <-> global EMF registry
> syncer plugin?
From the context menu of an EClass you have opened in the *.ecore
editor, you can invoke Create Dynamic Instance...
>
> The obvious workaround is of course to start a runtime workbench, but
> that is a rather harsh setback for the development workflow.
>
> Regards
> Marius
Re: Ecore definition and model instances in the same workbench [message #986919 is a reply to message #986815] Thu, 22 November 2012 11:21 Go to previous messageGo to next message
Eclipse User
Hello Ed,

On 21.11.2012 19:05, Ed Merks wrote:
>> is there a way to open a generic EMF editor to create and edit instances
>> (as XMI files) of an Ecore model which is developed in the same
>> workbench?
> Yes.
>> And along the same line, is there a way to have such and XMI
>> file be validated against that .ecore?
> Yes.

Almost.. see below.

>> I think this is some kind of
>> chicken-and-egg issue. So I've been wondering if there is already
>> somewhere some magic kind of workspace/*.ecore <-> global EMF registry
>> syncer plugin?
> From the context menu of an EClass you have opened in the *.ecore
> editor, you can invoke Create Dynamic Instance...

Thanks!

I experimented a bit with this using an existing .ecore model. I could
create a model instance and indeed I got validation errors both in the
reflective EMF editor and problem markers when I had not initialized
some mandatory attributes. Next I created a new attribute in a class
(type EInt, lowerBound=1, no default literal, unsettable = false). I did
not get a Problem Marker for this, but the new attribute did appear in
the editor (with a default value of 0). I would have expected to get an
error there.

Next I removed the new attribute from the class again. Again there were
no problem markers. Right-clicking the .xmi file and choosing Validate..
did succeed! Only when I loaded the XMI into the reflective EMF editor,
I did get an error about an unknown attribute. But still no problem marker.

Do I need a special builder perhaps for this?

Regards
Marius
Re: Ecore definition and model instances in the same workbench [message #987074 is a reply to message #986919] Fri, 23 November 2012 10:11 Go to previous messageGo to next message
Eclipse User
On 22.11.2012 12:21, Marius Gröger wrote:
> Next I removed the new attribute from the class again. Again there were
> no problem markers. Right-clicking the .xmi file and choosing Validate..
> did succeed! Only when I loaded the XMI into the reflective EMF editor,
> I did get an error about an unknown attribute. But still no problem marker.

I have tried this again with different models, but no joy.

What is Right-click .xmi -> Validate... supposed to validate anyway?

Regards
Marius
Re: Ecore definition and model instances in the same workbench [message #987083 is a reply to message #986919] Fri, 23 November 2012 11:28 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26088
Registered: July 2009
Senior Member
Marius,

Comments below.

On 22/11/2012 12:21 PM, Marius Gröger wrote:
> Hello Ed,
>
> On 21.11.2012 19:05, Ed Merks wrote:
>>> is there a way to open a generic EMF editor to create and edit instances
>>> (as XMI files) of an Ecore model which is developed in the same
>>> workbench?
>> Yes.
>>> And along the same line, is there a way to have such and XMI
>>> file be validated against that .ecore?
>> Yes.
> Almost.. see below.
>
>>> I think this is some kind of
>>> chicken-and-egg issue. So I've been wondering if there is already
>>> somewhere some magic kind of workspace/*.ecore <-> global EMF registry
>>> syncer plugin?
>> From the context menu of an EClass you have opened in the *.ecore
>> editor, you can invoke Create Dynamic Instance...
> Thanks!
>
> I experimented a bit with this using an existing .ecore model. I could
> create a model instance and indeed I got validation errors both in the
> reflective EMF editor and problem markers when I had not initialized
> some mandatory attributes. Next I created a new attribute in a class
> (type EInt, lowerBound=1, no default literal, unsettable = false). I did
> not get a Problem Marker for this, but the new attribute did appear in
> the editor (with a default value of 0). I would have expected to get an
> error there.
Primitives are a bit special. They can't take on a null value so how
best to establish if such a feature violates the constraint that a value
must be present? The validator treats non-unsettable and unsettable
features different in this regard. An unsettable feature must be set
(eIsSet must be true) to satisfy the lower bound of 1 constraint. A
non-unsettable feature must have a non-null value to satisfy the lower
bound of 1 constraint. As such, a primitive-valued non-unsettable
feature can't violate the lower bound of 1 constraint.
>
> Next I removed the new attribute from the class again. Again there were
> no problem markers. Right-clicking the .xmi file and choosing Validate..
> did succeed! Only when I loaded the XMI into the reflective EMF editor,
> I did get an error about an unknown attribute. But still no problem marker.
Problem markers are not created as a side effect of loading a resource.
>
> Do I need a special builder perhaps for this?
The Xtext folks provide a builder that validates Ecore and GenModel
resources so a project with an Xtext nature would do that, but EMF does
not provide such a builder.
>
> Regards
> Marius
>
Re: Ecore definition and model instances in the same workbench [message #987084 is a reply to message #987074] Fri, 23 November 2012 11:29 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26088
Registered: July 2009
Senior Member
Marius,

As I implied in your other post, if you want to detect that a
primitive-valued feature violates a lower bound constraint, you'll have
to make it unsettable.

On 23/11/2012 11:11 AM, Marius Gröger wrote:
> On 22.11.2012 12:21, Marius Gröger wrote:
>> Next I removed the new attribute from the class again. Again there were
>> no problem markers. Right-clicking the .xmi file and choosing Validate..
>> did succeed! Only when I loaded the XMI into the reflective EMF editor,
>> I did get an error about an unknown attribute. But still no problem marker.
> I have tried this again with different models, but no joy.
>
> What is Right-click .xmi -> Validate... supposed to validate anyway?
>
> Regards
> Marius
Re: Ecore definition and model instances in the same workbench [message #987610 is a reply to message #987083] Tue, 27 November 2012 10:29 Go to previous messageGo to next message
Eclipse User
On 23.11.2012 12:28, Ed Merks wrote:
>> Next I removed the new attribute from the class again. Again there were
>> no problem markers. Right-clicking the .xmi file and choosing Validate..
>> did succeed! Only when I loaded the XMI into the reflective EMF editor,
>> I did get an error about an unknown attribute. But still no problem
>> marker.
> Problem markers are not created as a side effect of loading a resource.
>>
>> Do I need a special builder perhaps for this?
> The Xtext folks provide a builder that validates Ecore and GenModel
> resources so a project with an Xtext nature would do that, but EMF does
> not provide such a builder.

I have taken a look a the org.eclipse.wst.validation.validator EP and
began writing a simple validator which is activated on *.xmi IFile
resources. Essentially this validator loads the .xmi file to be checked.
A customized EcoreBuilder then attempts to associate an .ecore file with
the loaded resource and validates it using Diagnostician.

While this kind of works, two questions arise:

1) Overriding the DefaultEcoreBuilder with code searching for an .ecore
appears clumsy to me. When the .xmi file contains an .ecore
schemLocation this should not be necessary. But AFACT the
DefaultEcoreBuilder seems to only handle XSD and xsd schema locations
natively?

2) Obviously any errors detected by the Diagnostician don't have
line/column numbers associated with them. Is there anyway to load an XMI
resource to track this? Otherwise I can't create meaningful problem
markers and this whole thing becomes almost pointless!

TIA
Marius
Re: Ecore definition and model instances in the same workbench [message #987621 is a reply to message #987610] Tue, 27 November 2012 10:47 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26088
Registered: July 2009
Senior Member
Marius,

Comments below.

On 27/11/2012 11:29 AM, Marius Gröger wrote:
> On 23.11.2012 12:28, Ed Merks wrote:
>>> Next I removed the new attribute from the class again. Again there were
>>> no problem markers. Right-clicking the .xmi file and choosing Validate..
>>> did succeed! Only when I loaded the XMI into the reflective EMF editor,
>>> I did get an error about an unknown attribute. But still no problem
>>> marker.
>> Problem markers are not created as a side effect of loading a resource.
>>> Do I need a special builder perhaps for this?
>> The Xtext folks provide a builder that validates Ecore and GenModel
>> resources so a project with an Xtext nature would do that, but EMF does
>> not provide such a builder.
> I have taken a look a the org.eclipse.wst.validation.validator EP and
> began writing a simple validator which is activated on *.xmi IFile
> resources. Essentially this validator loads the .xmi file to be checked.
> A customized EcoreBuilder then attempts to associate an .ecore file with
> the loaded resource and validates it using Diagnostician.
>
> While this kind of works, two questions arise:
>
> 1) Overriding the DefaultEcoreBuilder with code searching for an .ecore
> appears clumsy to me. When the .xmi file contains an .ecore
> schemLocation this should not be necessary. But AFACT the
> DefaultEcoreBuilder seems to only handle XSD and xsd schema locations
> natively?
Yes, it assumes there are XML Schema's being referenced.
>
> 2) Obviously any errors detected by the Diagnostician don't have
> line/column numbers associated with them. Is there anyway to load an XMI
> resource to track this?
No.
> Otherwise I can't create meaningful problem
> markers and this whole thing becomes almost pointless!
EMF creates problem markers that associate the URIs of the objects so if
you double click them the editor selects the right objects without
knowing their location in the source. You can reuse the utilities in
org.eclipse.emf.edit.ui.util.EditUIMarkerHelper, i.e.,
createMarkers(Diagnostic).
>
> TIA
> Marius
>
>
Re: Ecore definition and model instances in the same workbench [message #987633 is a reply to message #987621] Tue, 27 November 2012 11:27 Go to previous messageGo to next message
Eclipse User
On 27.11.2012 11:47, Ed Merks wrote:
>> Otherwise I can't create meaningful problem
>> markers and this whole thing becomes almost pointless!
> EMF creates problem markers that associate the URIs of the objects so if
> you double click them the editor selects the right objects without
> knowing their location in the source. You can reuse the utilities in
> org.eclipse.emf.edit.ui.util.EditUIMarkerHelper, i.e.,
> createMarkers(Diagnostic).

Actually I'd been using MarkerHelper already but didn't know there were
even more useful extension to it. The one you mention however seems to
rely on (non-existent) line/column information in the Diagnostics.

I found
org.eclipse.emf.edit.ui.action.ValidateAction.EclipseResourcesUtil which
seems at least to adjust markers with EMF resources but doesn't attach
LOCATION tags to the markers.

Do you have any more clues to get this working?

Thanks
Marius
Re: Ecore definition and model instances in the same workbench [message #987637 is a reply to message #987633] Tue, 27 November 2012 11:54 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26088
Registered: July 2009
Senior Member
Marius,

Comments below.

On 27/11/2012 12:27 PM, Marius Gröger wrote:
> On 27.11.2012 11:47, Ed Merks wrote:
>>> Otherwise I can't create meaningful problem
>>> markers and this whole thing becomes almost pointless!
>> EMF creates problem markers that associate the URIs of the objects so if
>> you double click them the editor selects the right objects without
>> knowing their location in the source. You can reuse the utilities in
>> org.eclipse.emf.edit.ui.util.EditUIMarkerHelper, i.e.,
>> createMarkers(Diagnostic).
> Actually I'd been using MarkerHelper already but didn't know there were
> even more useful extension to it. The one you mention however seems to
> rely on (non-existent) line/column information in the Diagnostics.
For ResourceDiagnostics we often have line information, but not from the
validator.
>
> I found
> org.eclipse.emf.edit.ui.action.ValidateAction.EclipseResourcesUtil which
> seems at least to adjust markers with EMF resources but doesn't attach
> LOCATION tags to the markers.
Yes, as I said we simply don't have them so that's not going to work...
>
> Do you have any more clues to get this working?
Create them like you see in ValidateAction.
>
> Thanks
> Marius
>
Re: Ecore definition and model instances in the same workbench [message #987644 is a reply to message #987637] Tue, 27 November 2012 12:18 Go to previous messageGo to next message
Eclipse User
On 27.11.2012 12:54, Ed Merks wrote:
> Marius,
>
> Comments below.
>
> On 27/11/2012 12:27 PM, Marius Gröger wrote:
>> On 27.11.2012 11:47, Ed Merks wrote:
>>>> Otherwise I can't create meaningful problem
>>>> markers and this whole thing becomes almost pointless!
>>> EMF creates problem markers that associate the URIs of the objects so if
>>> you double click them the editor selects the right objects without
>>> knowing their location in the source. You can reuse the utilities in
>>> org.eclipse.emf.edit.ui.util.EditUIMarkerHelper, i.e.,
>>> createMarkers(Diagnostic).
>> Actually I'd been using MarkerHelper already but didn't know there were
>> even more useful extension to it. The one you mention however seems to
>> rely on (non-existent) line/column information in the Diagnostics.
> For ResourceDiagnostics we often have line information, but not from the
> validator.
>>
>> I found
>> org.eclipse.emf.edit.ui.action.ValidateAction.EclipseResourcesUtil which
>> seems at least to adjust markers with EMF resources but doesn't attach
>> LOCATION tags to the markers.
> Yes, as I said we simply don't have them so that's not going to work...
>>
>> Do you have any more clues to get this working?
> Create them like you see in ValidateAction.

I'm very confused now. :-) Initially you indicated that I *don't* need
line information for error markers created by EditUIMarkerHelper.

I found out this doesn't seem to be true.

But the ValidateAction.EclipseResourcesUtil.createMarkers() doesn't work
either, even though ValidateAction.EclipseResourcesUtil.adjustMarker()
is being used.

Now what do you refer to with "like you see in ValidateAction"?!

Marius
Re: Ecore definition and model instances in the same workbench [message #987694 is a reply to message #987644] Tue, 27 November 2012 16:10 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26088
Registered: July 2009
Senior Member
Marius,

Comments below.

On 27/11/2012 1:18 PM, Marius Gröger wrote:
> On 27.11.2012 12:54, Ed Merks wrote:
>> Marius,
>>
>> Comments below.
>>
>> On 27/11/2012 12:27 PM, Marius Gröger wrote:
>>> On 27.11.2012 11:47, Ed Merks wrote:
>>>>> Otherwise I can't create meaningful problem
>>>>> markers and this whole thing becomes almost pointless!
>>>> EMF creates problem markers that associate the URIs of the objects so if
>>>> you double click them the editor selects the right objects without
>>>> knowing their location in the source. You can reuse the utilities in
>>>> org.eclipse.emf.edit.ui.util.EditUIMarkerHelper, i.e.,
>>>> createMarkers(Diagnostic).
>>> Actually I'd been using MarkerHelper already but didn't know there were
>>> even more useful extension to it. The one you mention however seems to
>>> rely on (non-existent) line/column information in the Diagnostics.
>> For ResourceDiagnostics we often have line information, but not from the
>> validator.
>>> I found
>>> org.eclipse.emf.edit.ui.action.ValidateAction.EclipseResourcesUtil which
>>> seems at least to adjust markers with EMF resources but doesn't attach
>>> LOCATION tags to the markers.
>> Yes, as I said we simply don't have them so that's not going to work...
>>> Do you have any more clues to get this working?
>> Create them like you see in ValidateAction.
> I'm very confused now. :-) Initially you indicated that I *don't* need
> line information for error markers created by EditUIMarkerHelper.
I thought the code that's in the validator action was there...
>
> I found out this doesn't seem to be true.
>
> But the ValidateAction.EclipseResourcesUtil.createMarkers() doesn't work
> either, even though ValidateAction.EclipseResourcesUtil.adjustMarker()
> is being used.
What do you mean by it doesn't work? When these markers are used in the
generate editors they select the object with the problem.
>
> Now what do you refer to with "like you see in ValidateAction"?!
The code you refer to above, i.e., the adjustMarker override...
>
> Marius
>
Re: Ecore definition and model instances in the same workbench [message #987780 is a reply to message #987694] Wed, 28 November 2012 07:20 Go to previous message
Eclipse User
On 27.11.2012 17:10, Ed Merks wrote:
>> But the ValidateAction.EclipseResourcesUtil.createMarkers() doesn't work
>> either, even though ValidateAction.EclipseResourcesUtil.adjustMarker()
>> is being used.
> What do you mean by it doesn't work? When these markers are used in the
> generate editors they select the object with the problem.

Mystery solved - in my testing workbench I had previously opened the
erratic file with the XML editor. Double clicking the error marker then
always opened the XML editor and neither of the generic or reflective
EMF editors. It works now.

Thanks!
Marius
Previous Topic:[CDO] CDO 4.1 &amp; 4.2 compatibility with older Eclipse versions
Next Topic:[EMF] Implementing Instance Model Inheritance
Goto Forum:
  


Current Time: Wed Oct 01 08:27:37 GMT 2014

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

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