Editing .feature file causes "Error executing EValidator" in latest veresion of Eclipse #87
Comments
|
Please provide exact version of Eclipse, JVM and Natural plugin in use along with anything else you might consider relevant for diagnosing. |
rlogiacco
added
the
Critical
|
Hi, thank you for replying. Eclipse: Natural: Java: As far as other details for diagnosing, I am not sure what useful info I can provide. I recreated it just now by installing Natural and restarting Eclipse. I opened a .feature file, and made a simple edit (add a carriage return at the end of the file). The error immediately pops up on the file. I am also unable to ctrl+click on the steps to go to the linked Step file, and if I modify a step to some invalid value, there is no indication that the step definition does not exist. Between myself and my team members, this is happening consistently on Windows 10 machines, Windows 10 VMs, and Linux VMs.
|
|
@mikeauen It could be also interesting which Xtext version you use. |
|
@miklossy , Here is the XText info: org.eclipse.xtext (2.22.0.v20200602-1352) "Xtext" [Active] |
|
Thanks! Do you see any entries in the Error View? |
|
@miklossy This is interesting. Yesterday I was seeing errors (Xtext related) in the Problems log. But now that I have reinstalled the plugin those are not showing up. Also, the files would show red error X's in the package explorer view on the left hand side. Today they are not. Unfortunately, I do not have a screenshot of the errors that were shown yesterday. Also to note, When I have the Error view open, nothing shows up there when the error appears.
|
|
I mean the Error view, not the Problem view. |
|
@miklossy The Error view is not showing anything today when the error occurs. I do not recall if it was yesterday. |
|
And how about the Eclipse Log file? |
|
@miklossy This is interesting. I see some errors in the log related to the string variables in the step definitions. Does Natural plugin require the string definitions in the step definitions to use regex for the strings (ie. "I navigate to {string} in the left hand menu" vs. something like "I navigate to "[^\"]*" in the left hand menu"... apologies if my regex example is wrong, it has been a while since I used it). I see entries like this in the attached error log: |
|
I just noticed: what do you have at line 1 in the feature file? Please post an example feature file which causes the problem. |
rlogiacco
added
Issue
|
@rlogiacco Line 1 is just tags. Here is an example: |
|
Based on the stacktrace from @mikeauen I could reproduce the problem with the following java program: Executing this java program produces the same exception: The problem can be fixed by quoting the @drkstr101 Could you please take a look and provide a PR with the corresponding fix?
|
|
This is using cucumber-jvm5 compatible syntax. In theory it should not be that difficult to add support in next. I had some WIP updates to the stepmatcher, but had backed them out to focus on the grammar lang for this release. In theory we just need to iterate the |
|
This is a lot more involved than I originally thought. However, the upcoming release should treat these as a mismatched step, which would then be a configurable warning rather than a straight-up runtime exception thrown during validation. |
|
@miklossy Thanks for the tip! I've added some additional error protection as you pointed out in your example. I should have tested against this new syntax once the stepmatcher was updated to target the new Gherkin annotation namespace. I've added an example to the stepmatcher test, and it is now at least flagging it as a mismatched step rather than a runtime exception. Perhaps we could add at least add some simple token matchers for things like |
|
For having it working as expected in relation to step matching we will have
to:
1. Define a new non-terminal element
2. match curly braces and store the content
3. find if a method with the appropriate annotation and name exists in the
glue codebase
We can decide to skip the third step (I believe it's not going to be a very
fast operation) and avoid the storing part of the second step, but that
will imply either limited usability of the click-through feature or a true
pain in the ass.
…On Thu, Sep 10, 2020 at 2:29 AM Aaron R Miller ***@***.***> wrote:
@miklossy <https://github.com/miklossy> Thanks for the tip! I've added
some additional error protection
<https://github.com/rlogiacco/Natural/blob/4b29b1c817e664eaefec0c4b13e243e98adb25ad/org.agileware.natural.stepmatcher.ui/src/org/agileware/natural/stepmatcher/ui/JavaAnnotationMatcher.java#L35>
as you pointed out in your example. I should have tested against this new
syntax once the stepmatcher was updated to target the new Gherkin
annotation namespace. I've added an example to the stepmatcher test, and it
is now at least flagging it as a mismatched step rather than a runtime
exception. Perhaps we could add at least add some simple token matchers for
things like {string} and {number}. Like something that can be done in a
few lines of code.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#87 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABQWMJ7BKWCSAGI3XMM4D3SFAMVVANCNFSM4QHQWULA>
.
|
|
What About something like this? public class CucumberExpressionValidator {
private static final Pattern TOKEN_PATTERN = Pattern.compile("(?|({\\w+})|(\\(\\w+(\\s\\w+)?\\)))");
public static boolean isMatchingAnnotationValue(final String annotationValue, final String description) {
return matchRegex(annotationValue, description) || matchExpression(annotationValue, description);
}
private static boolean matchRegex(final String annotationValue, final String description) {
try {
return description.matches(Pattern.quote(annotationValue));
} catch (final PatternSyntaxException e) {
// PASS
}
return false;
}
private static boolean matchExpression(final String annotationValue, final String description) {
int lastIndex = 0;
final StringBuilder result = new StringBuilder();
final Matcher matcher = TOKEN_PATTERN.matcher(annotationValue);
while (matcher.find()) {
result.append(annotationValue, lastIndex, matcher.start()).append(convertToken(matcher.group(1)));
lastIndex = matcher.end();
}
if (lastIndex < annotationValue.length()) {
result.append(annotationValue, lastIndex, annotationValue.length());
}
try {
return description.matches(Pattern.quote(result.toString()));
} catch (final PatternSyntaxException e) {
e.printStackTrace();
}
return false;
}
private static String convertToken(final String token) {
// TODO replace with equiv regex
return token;
}
}This might be a little slow, however. I am not sure how best to branch between the two forms. |
|
I would keep this aside for now: let's focus on what we currently have. Once we get it working as expected we start adding features |
|
Agreed. |
|
Hi Team, And this is the error I am getting on my Error Logs java.util.regex.PatternSyntaxException: Illegal repetition near index 24
|
When using the latest Natural plugin in the latest Eclipse to edit feature files, an error is immediately thrown in the file "Error executing EValidator". Not only is the error shown, but it also seems to prevent ctrl+click on the steps linking to the step files. Every developer on my team sees this same problem, but I cannot find anyone else complaining about this when doing google searches. Could this be a bug in the plugin, or is there a known way to address this in Eclipse?
The text was updated successfully, but these errors were encountered: