[Feature Request] - Enable downstream consumers to plugin in DSL customizations

[krmahadevan]

Currently Karate lets users plugin in customisations by letting users to add in their custom implementations (such as make a gRPC call or a DB call or a Unix ssh etc.,) via the Java.type() syntax.

For e.g., assuming that one has a need to do ssh operations for which one would like to use karate, then one needs to make use of

def SshClient = Java.type('com.foo.bar.SshClient')
def client = new SshClient(localhost,21)

This kind of takes away the readability of a feature file and requires that a person knows a bit more about programming to be able to understand what happens here and how to go about tracing the call.

If a user forgets to add comments for reach of these def statements, then the report gets polluted with all these code lines being shown up in the Karate reports instead of some english statements.

This issue tracks the following asks (I will be raising a PR for this as well shortly)

• As a Karate user, I should be able to come up with my own DSL (similar to how we have keywords defined in com.intuit.karate.ScenarioActions)
• I should be able to plugin my custom DSL into Karate and leverage everything else that Karate provides me.

Here's an example of what I am looking for

Feature: Greet Feature

  Scenario: Greet scenario
    * def name = 'Dragon Warrior'
    * greet name

[ptrthomas]

@krmahadevan this has been discussed in detail in #398

you can choose to submit a PR after reading the whole thread to propose an implementation, but as of now I consider it unlikely that we support what you ask for

[krmahadevan]

@ptrthomas - Would you be willing to atleast take a look at the PR because its not aimed at taking any of the cucumber route etc., but all its doing is just to facilitate a user to be able to plugin their own constructs, and Karate merely honours them.

If after looking at the PR, you still feel its not going to be taken, I am fine with it. I can always override the CLASSPATH locally (lock down on a Karate version in my test project) and still wire in this capability in my project and solve my problem statement.

Here's the PR: #1911

[ptrthomas]

@krmahadevan I looked at the PR. it is clearly not the approach I want to take especially with the dependency on cucumber.api.java.en.When. there's also a Plugin interface I've been exploring, but not completed: https://github.com/karatelabs/karate/blob/v1.2.0.RC1/karate-core/src/main/java/com/intuit/karate/core/Plugin.java

thanks for the suggestions and feedback, right now I'm just extremely careful about extra keywords and it will open up questions and edge cases on life-cycle, reporting and debugging - and I personally think scripting via JS is the priority.

[krmahadevan]

@ptrthomas - Sure. I just piggy backed on what was already there in ScenarioActions and hence the @When annotation reference.

[ptrthomas]

@krmahadevan which is itself a hack: https://github.com/karatelabs/karate/blob/v1.2.0.RC1/karate-core/src/main/java/cucumber/api/java/en/When.java