Why are the Geb examples by build tool?

[Poundex]

I would have expected the examples to have been for the different test frameworks that Geb has integrations with (Spock, JUnit, TestNG, etc...), but the current examples are one for Gradle, one for Maven, and then one for Cucumber? As well as one of these not being like the others, I don't understand considering that Geb itself doesn't need any build tool support, plugins, code generation etc. The only time Geb is not simply just another dependency is if there is no Groovy compilation set up (this is a one-liner in Gradle, and is a common plugin stanza in Maven).

We were talking about making the examples more front & centre (moving them into the main repo, making sure they're built in CI with everything else so we always know they're not broken) so was just wondering what are the most valuable things for users that will be shown by example?

[jonnybot0]

I think the examples serve basically one key purpose: They make Geb as accessible as possible to people working in different contexts. Remember, not everyone tasked with implementing browser testing is a savvy engineer who can easily switch between maven, gradle, ant, or whatever build tool is hot these days. Having examples in different build tool contexts makes the project accessible, and that's important for adoption.

I think the examples of using Geb with different services like SauceLabs, BrowserStack, and LambdaTest serve a similar purpose. Ideally, we would have examples using things like Selenium Grid and other current tech.

I agree that "Gradle, Maven, Cucumber" feels a little offbeat, since it's two build tools and a BDD tool. We'd need to have some thought about how to organize example modules. To me, the gold standard for this in the JVM world is the jmh-samples submodule of the Java Microbenchmark Harness. Something like one submodule with many submodules inside of it, each showing how to use Geb in different ways or contexts is the core idea.