remove cucumber compatibility and stop depending on legacy cucumber code

[ptrthomas]

refer this issue: #2189

this will require us to use a custom parser that gets us out of the cucumber "step regex" that has been the engine for the last 6 years. now that we have official plugins and extensions for IDEs, it is time to make this shift

benefits:

• we have been bundling a very old cucumber dependency info.cukes:cucumber-java:1.2.5 just for keeping cucumber plugins in IntelliJ and Eclipse happy. context is here: Karate engine re-write - exit from Cucumber but retain 100% syntax backwards compatibility #444 (comment) - and now we can jettison this
• today we use reflection to "interpret" each step when running a feature, this is how Cucumber works, but we can switch to a more traditional object-model and possibly get a performance improvement
  • also opens up some code analysis, formatting, and conversion, for e.g. a builder to generate karate files or convert to other formats
• we can better provide some IDE features such as IntelliSense and auto-complete in the official extensions without being hampered by Cucumber
• we may even be able to drop the requirement of starting each line with * Given When And etc
• open the way for doing some linting and static-code analysis tools for Karate
• we can bend the rules of the Gherkin syntax where it makes sense. for example,
  • to call other features
  • mark sections for documentation, examples, dynamic data sources

[ptrthomas]

developer note: refer #1913 - this code has to be cleaned up, we are also planning to remove the continueOnStepFailure option - as no one seems to be using it, and it un-necessarily complicates the code (in my opinion)

please shout if any concerns cc @joelpramos

[ptrthomas]

@kirksl please note this commit as part of refactoring and cleanup for 1.4.0 a6e6f51

we will no longer emit the karate-debug-port.txt file to be consistent with vs code best practices and for performance, port detection should be via the process output, and the official plugins do this already, we also had some issues with creating files. FYI in case you are still maintaining the karate-runner, thx !

[joelpramos]

Still have several teams using it and I recall questions on stackoverflow. The linked PR explains why and we use it widely - why do you think no one uses and what’s the need to remove?

[ptrthomas]

@joelpramos as far as I know there were 2 questions from people who perhaps tried it with no follow-up. in my opinion it is one of those things that people feel makes sense - but never actively use on a daily basis. I honestly think this is not a deal-breaker for karate, but of course just my opinion

anyway the main reason for removal is because it gets in the way of moving out of the cucumber regex approach. I believe after we complete that, we will use a DSL grammar which gives us a blank-slate to re-design the continueOnStepFailure approach. just for the record I was never in favor of adding this and it makes it harder for me to maintain the scenario-engine / runtime code.

[kirksl]

@kirksl please note this commit as part of refactoring and cleanup for 1.4.0 a6e6f51

we will no longer emit the karate-debug-port.txt file to be consistent with vs code best practices and for performance, port detection should be via the process output, and the official plugins do this already, we also had some issues with creating files. FYI in case you are still maintaining the karate-runner, thx !

Thanks for the heads up @ptrthomas
kirksl/karate-runner#166

[joelpramos]

Shouldn’t get in the way of the rewrite (I haven’t been following recently but I’m sure there’s very good reason). Why don’t you proceed with rewrite, remove this keyword, and we’ll discuss a redesign after?

note the original intent which was just to be able to get information of all the matches that failed and not fail on the 1st one to avoid cases of fail/fix/fail etc. maybe we can consider a “multi match block” with syntax where we can put multiple statements (like the new line alternative right now) and that shouldn’t require to preserve state across each execution which is the odd part of the design right now, not really aligned with the rest of karate - just a thought of another way to go at it

[joelpramos]

Now that I think about it the only reason why it was expanded to more keywords support was more cause we could and had to do some funky work to identify the type of keyword anyways - and still had to somehow many this not a hack that people could use it as if conditions to be truth to the original karate design

[joelpramos]

Sorry for back to back spam but kind of like the “multi match block” approach, maybe even if it just receives a JSON array of matches with a nice way of reporting it back - I’m sure a custom parser that you’re chasing will keep our options open / open more options

[ptrthomas]

@joelpramos I like the idea of a multi-match. let me try retain this keyword, but most likely I'll have to remove it when I do the cleanup and then we can add back continueOnStepFailure for 1.5 - we will certainly release a couple more RC releases for 1.4 to get wider feedback

[ptrthomas]

1.4.0 released -

• as of now continueOnStepFailure has not been removed
• cucumber-java 1.2.5 was removed from the pom.xml - this may impact IDE plugins that look for this JAR as a "marker" or support syntax coloring / running a test from the editor
• no other parser changes have been made, this is postponed for later - perhaps Karate 1.5

[mguzelel]

which means the cucumber for Java plugin is not supported anymore. are we going to use the Karate plugin?

[ptrthomas]

@mguzelel the karate plugins for vs code and intelliJ are recommended

[ericdriggs]

Intellij Cucumber java plugin will still work if you specify the Main class as: com.intuit.karate.cli.IdeMain

[ptrthomas]

Eclipse users have a workaround described here: https://stackoverflow.com/a/76294302/143475

[jeetendrae]

@ptrthomas, Please don't remove continueOnTestFailure. I am using it heavily and I need that keyword badly in future Karate releases also

[ptrthomas]

@jeetendrae noted. we got this feedback from others, and agreed, we will not remove it, thanks @joelpramos for the original contribution. I will be locking this thread now, it has gotten too long.