Initializing EMF-IncQuery validators command not (always) available from context menu

[Joost van Pinxten]

Hi guys,

Just tried to implement a constraint on my own EMF models, as I could not find the old STP BPMN update site and the new BPMN2 is not available yet.

What I found confusing, is that the validators need to be initialized explicitly. Once I knew that, I went looking for the context menu entry (as described in the BPMN validation example). However, during several runs, I have only been able to find that initialize command once... After that, the validation does work as expected.

I'm now unable to figure out how to get that command to show up in the context menu... My project consists of one query project, (containing 1 .eiq), the Xtext projects for my DSL and the generated model projects.

Is this a known issue?

Regards,
Joost

[Joost van Pinxten]

Steps that reproduce this for me:

* Create an ECore model with
  - EClass Model with a containment relation (0..*) to EClass ModelElement.
* Generate model, edit and editor code
* Register the EPackage in the registry (I do this through the context menu)
* Create an IncQuery project containing one .eiq with:

package dsl

import "dsl"

@Constraint (location="m", message = "test", severity = "warning")
pattern modelWithoutElements(m){
    Model(m);
    neg find modelWithElements(m);
}

pattern modelWithElements(m){
    Model.elements(m, _e);
}

Now run the workspace; there is no "Initialize EMF-IncQuery Validators." option in the menu.

On Eclipse Juno SR1 on Windows 7 x64.

Op vrijdag 25 januari 2013 14:43:12 UTC+1 schreef Joost van Pinxten het volgende:

[Zoltán Ujhelyi]

Hi,

thank you for the feedback about the validators. If possible, we will try to include a more detailed description of initializing the validators.

We decided to use the manual initialization method as we need do now know of any easy way to initialize the validators automatically for every possible editor type, so for now we have implemented a manual initialization method (using Eclipse commands). Basically, we try to support automatically the built-in generic EMF tree editors _and_ the generated editors of the imported metamodel packages. However, there might be cases when this is not enough - for that reason the Constraint annotation has an optional attribute to add an Eclipse editor ID where the contribution needs to be initialized.

I would like to ask as clarification what editor do you open your instance models in, and please also open the generated plugin.xml in the validation project, and please share what is generated from a selected constraint.

Cheers,
Zoltán

[Joost van Pinxten]

I'm not completely sure what parts you would like to see; so I've attached the whole project.

The generated plugin.xml shows one entry for an incquery runtime constraint. The ModelWithoutElementsConstraint0, matchers, matches etc are properly generated.

<?xml version="1.0" encoding="UTF-8"?>
<plugin>

   <extension
         id="validation.constraint.dsl.modelWithoutElements"
         point="org.eclipse.viatra2.emf.incquery.validation.runtime.constraint">
      <constraint
            name="dsl.modelWithoutElements"
            class="dsl.modelwithoutelements.ModelWithoutElementsConstraint0">
      </constraint>
   </extension>

</plugin>

Might try with a clean Eclipse this weekend.

Regards,
Joost


Op vrijdag 25 januari 2013 15:21:09 UTC+1 schreef Zoltán Ujhelyi het volgende:

[Joost van Pinxten]

It seems that this code is not generated in the plugin.xml when I'm registering the package through the EPackage registry (using the context menu on a .ecore file).

         <enabledForEditor
               editorId="dsl.presentation.DslEditorID">
         </enabledForEditor>

Now, I do get the warning that the generated code cannot be found. Although I think I'm exporting the model in the right way, it seems that something is not in order. Will check back here when I find the solution!

Op vrijdag 25 januari 2013 17:40:37 UTC+1 schreef Joost van Pinxten het volgende:

[Joost van Pinxten]

"The generated code of the Ecore model dsl cannot be found. Check the org.eclipse.emf.ecore.generated_package extension in the model project or consider setting up a generator model for the generated code to work."

However, this entry is present in the model plugin, and a search on Google does not show what plugin created this warning (i.e. EMF, Xtext or IncQuery, I'm guessing IncQuery). I don't know how to properly fix this, but I do know of a workaround: just use the .eiqgen, to register the genmodel, although it shows an error instead of a warning, the generated will be correct..

Op vrijdag 25 januari 2013 22:10:50 UTC+1 schreef Joost van Pinxten het volgende:

[Ujhelyi Zoltán]

Hi,

this fragment was exactly what I was looking for.

You say, it is not generated from a package from the EPackage registry - does the editor give a warning on the import declaration that the corresponding genmodel couldn't be found? I am asking, because that fragment is generated by looking at the genmodel of the package - and in case of the genmodel not available, there is no way to automatically infer this information.

If possible, I would look at the genmodel declarations; or if that does not provide the required results, then you could add this information using the optional attribute 'editorId' of the Constraint annotation.

Zoltán
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics

>>>> Now run the workspace; there is no "*Initialize EMF-IncQuery Validators*."

>>>> option in the menu.
>>>>
>>>> On Eclipse Juno SR1 on Windows 7 x64.
>>>>
>>>> Op vrijdag 25 januari 2013 14:43:12 UTC+1 schreef Joost van Pinxten het
>>>> volgende:
>>>>>
>>>>> Hi guys,
>>>>>
>>>>> Just tried to implement a constraint on my own EMF models, as I could
>>>>> not find the old STP BPMN update site and the new BPMN2 is not available
>>>>> yet.
>>>>>
>>>>> What I found confusing, is that the validators need to be initialized
>>>>> explicitly. Once I knew that, I went looking for the context menu entry (as
>>>>> described in the BPMN validation example). However, during several runs, I
>>>>> have only been able to find that initialize command once... After that, the
>>>>> validation does work as expected.
>>>>>
>>>>> I'm now unable to figure out how to get that command to show up in the
>>>>> context menu... My project consists of one query project, (containing 1
>>>>> .eiq), the Xtext projects for my DSL and the generated model projects.
>>>>>
>>>>> Is this a known issue?
>>>>>
>>>>> Regards,
>>>>> Joost
>>>>>
>>>>
>

> --
> You received this message because you are subscribed to the Google Groups "EMF-IncQuery Users" group.
> To post to this group, send email to incquer...@googlegroups.com.
> To unsubscribe from this group, send email to incquery-user...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msg/incquery-users/-/u4yxmrJ4QvUJ.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Joost van Pinxten]

Thanks Zoltán, yes, it does indeed give a warning (see my later message) when I try to use only the EPackage registry. I remember now that the Xtext MWE2 workflow also requires me to explicitly locate the locations of the genmodels. In order to develop my Xtext grammar and my models in the same workspace I need to use both (i.e. explicit registration of the genmodel and runtime registration of the DSL EPackages).

Wouldn't it make more sense to just convert the .eiqgen error to a warning (the error that is shown when both an EPackage entry and the genmodel are registered)? I might be confused, but it doesn't seem like it should stop the workspace from building/launching, and therefore is actually a warning, not an error?

Op vrijdag 25 januari 2013 22:47:31 UTC+1 schreef Zoltán Ujhelyi het volgende:

Hi,

this fragment was exactly what I was looking for.

You say, it is not generated from a package from the EPackage registry - does the editor give a warning on the import declaration that the corresponding genmodel couldn't be found? I am asking, because that fragment is generated by looking at the genmodel of the package - and in case of the genmodel not available, there is no way to automatically infer this information.

If possible, I would look at the genmodel declarations; or if that does not provide the required results, then you could add this information using the optional attribute 'editorId' of the Constraint annotation.

Zoltán
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics

[Ujhelyi Zoltán]

Hi,

sorry, I was thinking about another type of problem. If during the package resolution an imported EPackage could be resolved, but its corresponding genmodel couldn't (e.g. because of an incorrect registration in the plugin.xml of the model project), the eiq file reports a warning. But your issue shows another case.

About warning/error we already had some internal discussions about. As the presence of the issue the engine/tooling might work as expected in some cases (but not in others), it could be a warning. However, we decided to use the error marker to give a better visibility to the potential issue.

We are looking for better ways to report issues, but we also want to respect the guidelines of the Eclipse Platform, so we do not know yet how to do it better.

Zoltán
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics

>> incquery-users+noreply-APn2wQeyh...@googlegroups.com<javascript:>>

>>> To post to this group, send email to incquer...@googlegroups.com<javascript:>.

>>
>>> To unsubscribe from this group, send email to

>> incquery-user...@googlegroups.com <javascript:>.

>>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/incquery-users/-/u4yxmrJ4QvUJ.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups "EMF-IncQuery Users" group.
> To post to this group, send email to incquer...@googlegroups.com.
> To unsubscribe from this group, send email to incquery-user...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msg/incquery-users/-/-6dNeEVi_9MJ.

[Ábel Hegedüs]

The error message is indeed from EMF-IncQuery, it means that the EPackage is in the registry, but (a) if it is there based on a generated-package extension (read during startup), then the extension does not point to the genmodel file or (b) the EPackage ended up in the registry in some other way, and there is no way to find the genmodel or the generated code.

It shows an error, because you have two EPackages with the same nsUri, but they are different (one from the registry, one through eiqgen). In the current version this is an error, since choosing either EPackage will either cause the generated code or the Query Explorer to stop working correctly.

I have been meaning to ask, you included the following step in the reproduction:

"* Register the EPackage in the registry (I do this through the context menu)"

Can you elaborate on that?

You usually develop queries with EMF-IncQuery in two ways:

* When the EMF model project (with the ecore and genmodel files) is in the same workspace with the EMF-IncQuery project: in this case, you DO NOT have the EPackage in the registry, but create an EMF-IncQuery Generator Model (.eiqgen) file and add an entry referring to the genmodel file. In this case, information about the generated code is accessed through the genmodel (including the editor id).

* When the EMF model project is already installed as a bundle in the host, and therefore the EPackage is registered using the generated-package extension: in this case, you can simply add an import declaration to the .eiq file and use the metamodel. IF the extension contains a valid reference to the genmodel file, then EMF-IncQuery can access the information within (including the editor id)

One of the main causes of this behavior is that we need to ensure, that when you are using the queries after installing them into an Eclipse, the EClasses referred by the pattern definition are the same as the ones in the EPackage registry and the instance models.

I hope I managed to clear it up a bit.

Best regards,

   Ábel

____

http://about.me/abelhegedus/bio

--

You received this message because you are subscribed to the Google Groups "EMF-IncQuery Users" group.
To post to this group, send email to incquer...@googlegroups.com.
To unsubscribe from this group, send email to incquery-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/incquery-users/-/c9mzout03zIJ.

[Joost van Pinxten]

I see the reason for this behavior now, thank you for the elaborate response.

Op zaterdag 26 januari 2013 12:05:12 UTC+1 schreef Ábel Hegedüs het volgende:

The error message is indeed from EMF-IncQuery, it means that the EPackage is in the registry, but (a) if it is there based on a generated-package extension (read during startup), then the extension does not point to the genmodel file or (b) the EPackage ended up in the registry in some other way, and there is no way to find the genmodel or the generated code.

It shows an error, because you have two EPackages with the same nsUri, but they are different (one from the registry, one through eiqgen). In the current version this is an error, since choosing either EPackage will either cause the generated code or the Query Explorer to stop working correctly.

I have been meaning to ask, you included the following step in the reproduction:

"* Register the EPackage in the registry (I do this through the context menu)"

Can you elaborate on that?

My workspace consists of the EMF model project for the DSL, the Xtext editor for the DSL and and IncQuery project for the DSL. I've been investigating tools like Epsilon and they require you to register just the EPackages, as the engine uses the reflective EMF model, instead of the generated code.
 

You usually develop queries with EMF-IncQuery in two ways:

* When the EMF model project (with the ecore and genmodel files) is in the same workspace with the EMF-IncQuery project: in this case, you DO NOT have the EPackage in the registry, but create an EMF-IncQuery Generator Model (.eiqgen) file and add an entry referring to the genmodel file. In this case, information about the generated code is accessed through the genmodel (including the editor id).

* When the EMF model project is already installed as a bundle in the host, and therefore the EPackage is registered using the generated-package extension: in this case, you can simply add an import declaration to the .eiq file and use the metamodel. IF the extension contains a valid reference to the genmodel file, then EMF-IncQuery can access the information within (including the editor id)

So, in order to keep them into one workspace, I can use either IncQuery or Xtext but not both, without them showing errors.
 

One of the main causes of this behavior is that we need to ensure, that when you are using the queries after installing them into an Eclipse, the EClasses referred by the pattern definition are the same as the ones in the EPackage registry and the instance models.

I hope I managed to clear it up a bit.

Best regards,

   Ábel

____

http://about.me/abelhegedus/bio

[Istvan Rath]

Hi,

So, in order to keep them into one workspace, I can use either IncQuery or Xtext but not both, without them showing errors.

this depends on what you wish to use IncQuery for. For generic pattern matching/queries (through the UI, a.k.a. Query Explorer), nothing special is required, the EPackage needs to be resolvable somehow (either through the registry, or through the .eiqgen approach). Access to the ecore generated code is only required (at the moment) for the query generated code to compile and work and for extensions such as the Validation Framework.

If you do not need the generated code, a workaround is to disable the IncQuery compiler (through Preferences).

The point you raised is very much valid, though, and I opened a bugzilla to discuss this request on https://bugs.eclipse.org/bugs/show_bug.cgi?id=399357

regards

Istvan

[Joost van Pinxten]

Hi,

Op dinsdag 29 januari 2013 08:37:46 UTC+1 schreef István Ráth het volgende:

Hi,

So, in order to keep them into one workspace, I can use either IncQuery or Xtext but not both, without them showing errors

I've become used to the way Epsilon registers the metamodels; I do see now that this is not the most practical solution for tools that need access to the genmodel. So, in short, choose either of the two approaches described by Ábel, but do not mix the two, as it will lead to unwanted behavior. For rapid prototyping of your metamodel and Xtext editor, it is most convenient to just register the EPackage, but I'm just going to do this in a different workspace. (Exporting the bundle into the host and restarting the host is too time-consuming in the context of Xtext editor development).

 

this depends on what you wish to use IncQuery for. For generic pattern matching/queries (through the UI, a.k.a. Query Explorer), nothing special is required, the EPackage needs to be resolvable somehow (either through the registry, or through the .eiqgen approach). Access to the ecore generated code is only required (at the moment) for the query generated code to compile and work and for extensions such as the Validation Framework.

If you do not need the generated code, a workaround is to disable the IncQuery compiler (through Preferences).

The point you raised is very much valid, though, and I opened a bugzilla to discuss this request on https://bugs.eclipse.org/bugs/show_bug.cgi?id=399357

I'll keep an eye out for the solution to this bug, as it is certainly not trivial how to handle these cases.

regards

Istvan