Pattern with Custom Aggregator can not be loaded into Query Results View

[eclipse-viatra-bot]

| --- | --- |
| Bugzilla Link | 564405 |
| Status | UNCONFIRMED |
| Importance | P3 normal |
| Reported | Jun 18, 2020 05:14 EDT |
| Modified | Aug 20, 2020 04:25 EDT |
| Version | 2.3.2 |
| Reporter | Hans van der Laan |

Description

I’m trying to evaluate my custom aggregator in the Query Results View. Unfortunately, it can not be loaded. I’m getting the error that “Aggregator class cannot be found”

The patterns do compile and do not contain any errors. The query editor doesn’t give any errors. When I click on the custom aggregator, I also correctly jump to the class in which the custom aggregator was defined.

[eclipse-viatra-bot]

By Zoltan Ujhelyi on Jun 19, 2020 10:35

This is a case we have not tested before. The root cause of the problem is that the Java class representing the aggregator is only available in the workspace, but it needs to be executed in an interpreted way. By replacing its usage with XbaseInterpreter we might get this to work. I will try to have some time to look into this issue to see how much effort is required to provide a solution to the problem.

[eclipse-viatra-bot]

By Gabor Bergmann on Jun 19, 2020 12:53

Hans, maybe we can also find a valid workaround, depending on your workflow.

So if we go with the assumption that the custom aggregator is fine to use in a Java VM where it is actually loaded as a Java class, any of the following setups should work:

• You develop the custom aggregator in a host Eclipse, then start a runtime Eclipse from there, that loads the aggregator. In the runtime Eclipse, you develop your patterns that use this aggregator (make sure it is published from a dependency of the bundle project containing the queries). You can then get quick feedback using Query Results View to evaluate the query. Or, alternatively:

• You develop both the patterns and the custom aggregator in a host Eclipse, then start a runtime Eclipse from there, that loads both of these. In the runtime Eclipse, you use Query Results View to evaluate the query (and the query registry for loading the query in the first place).

Will any of these options help you?

[eclipse-viatra-bot]

By Hans van der Laan on Jun 22, 2020 05:07

Hey Gabor,

Unfortunately, I’m not very savy with Eclipse, so I’m not sure what you mean by “loading” classes in Eclipse.

At the moment, I’m using the generated model editor to test my patterns. My patterns are already in a separated module. I’ve tried adding them to the classpath of the generated model editor, but that doesn’t do the trick.

[eclipse-viatra-bot]

By Gabor Bergmann on Jun 22, 2020 11:16

I’ve tried adding them to the classpath of the generated model editor

That should be irrelevant.

I suggest trying one of the two setups I suggested above.

[eclipse-viatra-bot]

By Hans van der Laan on Jun 24, 2020 09:11

Sorry for the confusion. I meant that I'm not sure what exactly you mean by "loading the queries", "loading the aggregator", "publishing a class" and thus I do not know how I should do this.

I though that perhaps you meant that I should add them to the classpath, but I see this is not the case.

[eclipse-viatra-bot]

By Zoltan Ujhelyi on Jun 24, 2020 11:56

(In reply to Hans van der Laan from comment #5)

Sorry for the confusion. I meant that I'm not sure what exactly you mean by
"loading the queries", "loading the aggregator", "publishing a class" and
thus I do not know how I should do this.

I though that perhaps you meant that I should add them to the classpath, but
I see this is not the case.

The things you were asking and Gábor were suggesting are quite related.

For these aggregators to work, the aggregator class should be available on the classpath that is responsible for providing the query specifications in a form that can be executed. In the case of the generated code, this means the classpath of the plug-in being developed, in case of the Query Result view this is a generic plug-in provided by VIATRA. The original issue is that this generic view does not parse correctly the development classpath of the Java project you are developing.

The first solution proposed by Gábor will most likely not work, as the custom aggregator will not be visible for the query interpreter used by the Query Results view.

However, the second suggestion should work (even if it is a bit cumbersome): you write your patterns and let the code generator generate the query specifications. In addition to the Java code, in the plugin.xml file of the plug-in there will be a few extensions that allow the Query Result view to load these patterns in a runtime Eclipse.

What you need to do is the following:

1. Launch a runtime Eclipse with the patterns being developed.
2. Open a model in the editor and load it to the Query Result view as normal.
3. Then open the Query Registry view provided by VIATRA and search and select your patterns with the aggregator there.
4. Then the button for loading patterns should be enabled in the Query Result view to load this pattern.
5. Now you can test whether your patterns behave as you want.

I hope this makes it cleaner how to work around the issue for now.

[eclipse-viatra-bot]

By Hans van der Laan on Jun 25, 2020 03:36

In addition to the Java code, in the plugin.xml file of the plug-in there will be a few extensions that allow the Query Result view to load these patterns in a runtime Eclipse

Which plugin? The generated editor?

What you need to do is the following:

Does that mean, given I have already compiled the patterns and I have added the aggregators in the plugin.xml file?

If this isn't the case, I get the same error: "aggregator class cannot be found"

If this is the case, I have a different road block:

Whenever I generate the query specifications, the VQL editor will light up and I will get the warning "The type MyPattern is already defined in MyPattern .java." for every pattern.

This isn't a problem when developing patterns. It doesn't block a recompile and whenever I want to evaluate the patterns with the Query Result View, I just delete the generated patterns. However, this means that whenever I try to load a pattern into the query results view after I've generated the code, I'm greeted with an "Query Definition contains errors" warning for every query.

I've tried to turn off this warning. Setting the folders with the generated code as read-only/derived doesn't work.

[eclipse-viatra-bot]

By Zoltan Ujhelyi on Jun 25, 2020 04:58

(In reply to Hans van der Laan from comment #7)

In addition to the Java code, in the plugin.xml file of the plug-in there will be a few extensions that allow the Query Result view to load these patterns in a runtime Eclipse

Which plugin? The generated editor?

No, the plugin that defines the patterns.

What you need to do is the following:

Does that mean, given I have already compiled the patterns and I have added
the aggregators in the plugin.xml file?

If this isn't the case, I get the same error: "aggregator class cannot be
found"

The aggregators does not need to be registered, if the generated code of the pattern compiles, it should work - but only where the generated code is used, e.g. if you follow the steps from #6 - but you cannot edit these patterns in the runtime Eclipse, you can only execute the instances that were registered.\

If this is the case, I have a different road block:

Whenever I generate the query specifications, the VQL editor will light up
and I will get the warning "The type MyPattern is already defined in
MyPattern .java." for every pattern.

This isn't a problem when developing patterns. It doesn't block a recompile
and whenever I want to evaluate the patterns with the Query Result View, I
just delete the generated patterns. However, this means that whenever I try
to load a pattern into the query results view after I've generated the code,
I'm greeted with an "Query Definition contains errors" warning for every
query.

I've tried to turn off this warning. Setting the folders with the generated
code as read-only/derived doesn't work.

This is most likely caused by an incorrect project set up where the generated java classes and the vql files are set up in a way that is not consistent (and would result in duplicate Java classes after code generation finish). Nonetheless, I'd recommend not opening the project in the runtime workbench for editing, but relying on the query registry view to evaluate them.

[eclipse-viatra-bot]

By Hans van der Laan on Jun 25, 2020 06:55

No, the plugin that defines the patterns.

What is this plugin? Is it generated? I don't see a plugin.xml in the generated files.

The aggregators does not need to be registered, if the generated code of the pattern compiles, it should work - but only where the generated code is used, e.g. if you follow the steps from #6 - but you cannot edit these patterns in the runtime Eclipse, you can only execute the instances that were registered.

Furthermore, I think we might not mean the same thing with runtime Eclipse/runtime workbench. What I see as the "runtime eclipse" is the generated editor you start as an eclipse application. Do we mean the same thing?

[eclipse-viatra-bot]

By Zoltan Ujhelyi on Jun 25, 2020 07:01

(In reply to Hans van der Laan from comment #9)

No, the plugin that defines the patterns.

What is this plugin? Is it generated? I don't see a plugin.xml in the
generated files.

It is not in the src-gen folder but at the root of the plugin (it must be there because Eclipse plugins expect it there). If it's not there you might have turned off this generation in the Project settings or the Eclipse preferences at the VQL Compiler options page.

The aggregators does not need to be registered, if the generated code of the pattern compiles, it should work - but only where the generated code is used, e.g. if you follow the steps from #6 - but you cannot edit these patterns in the runtime Eclipse, you can only execute the instances that were registered.

Furthermore, I think we might not mean the same thing with runtime
Eclipse/runtime workbench. What I see as the "runtime eclipse" is the
generated editor you start as an eclipse application. Do we mean the same
thing?

Yes, that is the runtime workbench I am talking about. By default every plugin you develop in your host Eclipse (the one you start the runtime from) is also installed there, so the plugin with your patterns should be as well.

[eclipse-viatra-bot]

By Hans van der Laan on Jun 26, 2020 07:43

This is most likely caused by an incorrect project set up where the generated java classes and the vql files are set up in a way that is not consistent (and would result in duplicate Java classes after code generation finish). Nonetheless, I'd recommend not opening the project in the runtime workbench for editing, but relying on the query registry view to evaluate them.

Thanks, this really bugged me! I didn't know what caused this error, so I didn't know how to resolve it.

It is not in the src-gen folder but at the root of the plugin (it must be there because Eclipse plugins expect it there). If it's not there you might have turned off this generation in the Project settings or the Eclipse preferences at the VQL Compiler options page.

I'm still not sure what you mean. I only have 3 plugin.xml's in my project: one in the model project, one in the generated model.editor and one in the generated model.edit. I have not touched any VQL/Eclipse settings (except now the output folder), so I doubt I have turned anything off.

However, I'm fine at the moment without the Query Results View. My workaround at the moment is to just inspect the matches directly ("MyPattern.Matcher.on(engine).getAllMatches()").

[eclipse-viatra-bot]

By Hans van der Laan on Aug 19, 2020 10:32

(In reply to Zoltan Ujhelyi from comment #1)

This is a case we have not tested before. The root cause of the problem is
that the Java class representing the aggregator is only available in the
workspace, but it needs to be executed in an interpreted way. By replacing
its usage with XbaseInterpreter we might get this to work. I will try to
have some time to look into this issue to see how much effort is required to
provide a solution to the problem.

Has there been any progress on resolving this bug? :)

[eclipse-viatra-bot]

By Hans van der Laan on Aug 19, 2020 10:33

(Until now, I didn't really need this feature. However, my plan is to start performance testing in 2-3 weeks, and it would be nice to be able to inspect the matches of the sub patterns then.)

[eclipse-viatra-bot]

By Zoltan Ujhelyi on Aug 20, 2020 04:25

(In reply to Hans van der Laan from comment #13)

(Until now, I didn't really need this feature. However, my plan is to start
performance testing in 2-3 weeks, and it would be nice to be able to inspect
the matches of the sub patterns then.)

Sorry, but no. I had a quick look at it, but this issue requires some non-trivial work to do related to how classes need to be loaded from the classpath of the query projects instead of relying on Java reflection. Right now, I don't have any real workaround for the issue and I cannot even promise a timeline we will have time to tackle this.

---

Breadcrumbs for myself when I will continue the work:

• The problematic code is EPMToPBody#initializeAggregator where Class.forName() is used to access the required class that will not work in Eclipse environments for custom aggregators. For built-in aggregators it works, as they are on the classpath of the org.eclipse.viatra.query.patternlanguage.emf bundle, but it will never work for others.
• How to fix this: similar to the custom Xbase interpreter-based solution for check expressions we have to build an aggregator factory that wraps the JvmTypes into something the runtime can call. This will functionally work, but we have to expect slowdowns when the aggregator is called a lot of times (again, similar to check expressions). The bad news is that we might need to change the aggregator interfaces (but this is the reason we consider them experimental).