-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pattern with Custom Aggregator can not be loaded into Query Results View #124
Comments
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. |
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:
Will any of these options help you? |
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. |
By Gabor Bergmann on Jun 22, 2020 11:16
That should be irrelevant. I suggest trying one of the two setups I suggested above. |
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. |
By Zoltan Ujhelyi on Jun 24, 2020 11:56 (In reply to Hans van der Laan from comment #5)
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:
I hope this makes it cleaner how to work around the issue for now. |
By Hans van der Laan on Jun 25, 2020 03:36
Which plugin? The generated editor?
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. |
By Zoltan Ujhelyi on Jun 25, 2020 04:58 (In reply to Hans van der Laan from comment #7)
No, the plugin that defines the patterns.
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.\
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. |
By Hans van der Laan on Jun 25, 2020 06:55
What is this plugin? Is it generated? I don't see a plugin.xml in the generated files.
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? |
By Zoltan Ujhelyi on Jun 25, 2020 07:01 (In reply to Hans van der Laan from comment #9)
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.
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. |
By Hans van der Laan on Jun 26, 2020 07:43
Thanks, this really bugged me! I didn't know what caused this error, so I didn't know how to resolve it.
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()"). |
By Hans van der Laan on Aug 19, 2020 10:32 (In reply to Zoltan Ujhelyi from comment #1)
Has there been any progress on resolving this bug? :) |
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.) |
By Zoltan Ujhelyi on Aug 20, 2020 04:25 (In reply to Hans van der Laan from comment #13)
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:
|
| --- | --- |
| 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.
The text was updated successfully, but these errors were encountered: