Skip to main content
Jump to: navigation, search

Difference between revisions of "VIATRA/Query/UserDocumentation/DebuggerTooling"

< VIATRA‎ | Query
Line 16: Line 16:
  
 
We will place some breakpoints into the Query Explorer related UI code for the sake of the example.
 
We will place some breakpoints into the Query Explorer related UI code for the sake of the example.
 +
* LoadResourceSetHandler#execute -> place a breakpoint on the return statement. This code loads a new EMF instance model into the Query Explorer and a new EMF-IncQuery engine will be created.
 
*  
 
*  
 
   
 
   
Line 23: Line 24:
  
 
== Additional remarks ==
 
== Additional remarks ==
* OSGi vs Eclipse app debugging
+
* If you are repeatedly loading and unloading EMF instance models in the Query Explorer, you may see an already unloaded engine in the Variables View. This is because the garbage collector has not yet collected the engine.
 +
* If you are using the Variables View for an Eclipse application then you should remember that you need your plug-ins on "three levels". On the first (bottommost) level are the core IncQuery plug-ins, containing also the plug-in for the debug support. The Variables View is then loaded into the second level, and this is the level where it will be populated with the variables. The contents, however, will come from the third level, where you application is running. This has some important implications:
 +
a. The JVM on the second level needs to collect information from the JVM on the third level.
 +
b. If you have installed EMF-IncQuery into your host Eclipse, then it is enough to use "two levels", because the Variables View will be loaded into the host Eclipse.
 +
c. If you are using EMF-IncQuery with an OSGi application, then you can use the Variables View on the same level as you application.

Revision as of 11:52, 1 May 2014

The EMF-IncQuery debugger tooling aims to provide useful functionalities for the users, so that they can easily observe the contents of the EMF-IncQuery related artifacts when the program execution has stopped at a breakpoint. The plan is to provide three kinds of support for debugging:

  • Possibility to explore the contents of the EMF instance models
  • Navigation in the contents of EMF-IncQuery pattern matcher engines (matchers, matches, match parameters, etc)
  • Navigation in the contents of EMF-IncQuery Rule Engines

The idea was described in the corresponding Bugzilla issue https://bugs.eclipse.org/bugs/show_bug.cgi?id=405556.

The 0.8 version of EMF-IncQuery introduces support for the second point, the other two points will be implemented later. The debugger tooling is seamlessly integrated into the Eclipse Debug Perspective with additional views for the mentioned functionalities.

The features will be described with the emfxcel example (which is described in more details here https://incquery.net/incquery/examples/emfxcel). The example can be obtained from the GitHub repository https://github.com/ujhelyiz/EMF-IncQuery-Examples.

Debugging EMF-IncQuery engines

The latest version of EMF-IncQuery provides a new view which is called EMF-IncQuery Variables. This view is similar to the original Variables View (from the Debug Perspective), except that this one will display EMF-IncQuery pattern matcher engines when the application has halted at a breakpoint.

In this example we will place the net.istvanrath.emfxcel (note that this one will generate two additional plug-ins) and net.istvanrath.emfxcel.editor.xlsx plug-ins into the host Eclipse. Take these plug-ins and add them to an Eclipse Application Launch Configuration and start this configuration in Debug mode.

We will place some breakpoints into the Query Explorer related UI code for the sake of the example.

  • LoadResourceSetHandler#execute -> place a breakpoint on the return statement. This code loads a new EMF instance model into the Query Explorer and a new EMF-IncQuery engine will be created.



Additional remarks

  • If you are repeatedly loading and unloading EMF instance models in the Query Explorer, you may see an already unloaded engine in the Variables View. This is because the garbage collector has not yet collected the engine.
  • If you are using the Variables View for an Eclipse application then you should remember that you need your plug-ins on "three levels". On the first (bottommost) level are the core IncQuery plug-ins, containing also the plug-in for the debug support. The Variables View is then loaded into the second level, and this is the level where it will be populated with the variables. The contents, however, will come from the third level, where you application is running. This has some important implications:

a. The JVM on the second level needs to collect information from the JVM on the third level. b. If you have installed EMF-IncQuery into your host Eclipse, then it is enough to use "two levels", because the Variables View will be loaded into the host Eclipse. c. If you are using EMF-IncQuery with an OSGi application, then you can use the Variables View on the same level as you application.

Back to the top