Excellent! Thanks, James. On Wed, Sep 30, 2026 at 2:09 PM James Fredley <[email protected]> wrote:
> Hey Jonny, > > I am onboard with all of your suggestions. I'll update the PR with the > changes that I control and OK with calling it experimental. > > James > > On 2026-09-21 05:12 UTC Jonny wrote: > > Hey, everyone. First, big thanks to everyone who contributed to this > > discussion. > > > > Second, I am generally supportive of building a Geb layer that can use > > Playwright as a driver. Geb was deliberately built to use Selenium as an > > implementation detail, not at the API layer. Its content DSL and other > > features should, in principle, be implementable in Playwright's Java > > bindings. > > > > That said, my own experience with Playwright is a bit more mixed, and I > > have much lower confidence that it can deliver on less flaky browser > > testing promise. > > > > If our deeper objective here is to address flakiness, I'd like to > consider > > more deeply Selenium's support for WebDriver BiDi > > <https://www.selenium.dev/documentation/webdriver/bidi/>. They've > committed > > to moving much of Selenium's implementation to that without breaking > > backwards compatibility. So while James Daugherty's note about > Playwright's > > strength was true at its first release, I think that's less true today. > > Selenium should have access to the same event-driven strengths as > > Playwright via the open BiDi standard. While I can see that the > > AI-generated design has some words on this > > < > https://github.com/jdaugherty/groovy-geb/blob/master/design/geb-playwright-backend-plan.md#23-why-not-webdriver-bidi-inside-selenium-instead > >, > > it strikes me as... well, I don't quite trust the AI's analysis, frankly. > > There may be some grains of truth in the particulars, but I don't buy > that > > it would translate directly into a difference in flaky tests. Please feel > > free to prove me wrong if you've already got the builds to show > otherwise! > > > > A couple of thoughts: > > 1. I'd be more comfortable merging James Fredley's PR if we called the > > module geb-playwright instead of geb-direct. That way it would be clear > > exactly what the module's implementation was based on, and that its goal > > was to be an implementation on top of a specific vendor, similar to > > geb-spock and geb-junit. "geb-direct" sounds more fundamental than the > > module really is. > > 2. I'd prefer we mark it as an experimental feature. For personal > reasons, > > I've been fairly time-constrained lately and I don't think I'll have time > > to give that PR a proper review and test. > > 3. I'd like to throw some clankers at the PR for an antagonistic review > > centered around the idea of, "Is this the simplest thing that could > > possibly work? How could the same goal be accomplished with less code?" > and > > similar things. While the code at first glance doesn't have too many of > the > > hallmark traces of AI slop (i.e. overly verbose JavaDoc, etc.), I'm > always > > suspicious that the AI code generators are overcomplicating things. If > > someone wants to beat me to this, more power to you. > > > > Thanks very much for the enthusiastic contribution and your patience > while > > I've been getting caught up. > > > > Best, > > > > Jonny > > > > On Wed, Jul 22, 2026 at 1:21 PM James Fredley <[email protected]> > > wrote: > > > > > Since selenium continues to cause Flaky tests on the > > > https://github.com/apache/grails-core builds, I prioritized this. > > > > > > https://github.com/apache/groovy-geb/pull/330 - Add optional > geb-direct > > > Playwright backend, the PR also links to a grails-core repo branch > which > > > can be used to test this locally. > > > > > > I noticed some dependencies are not the most recent, on master, and I > > > would be glad to contribute PRs to update those also. > > > > > > James Fredley > > > VP, Apache Grails > > > > > > On 2026/07/03 23:00:51 James Fredley wrote: > > > > Hey folks, > > > > > > > > I’ve been thinking about ways to bring some of Playwright’s strengths > > > > (BrowserContext isolation, built-in auto-waiting for actionable > > > > elements, strong locator strategies, tracing with > > > > screenshots/DOM/network, video recording, and network interception) > into > > > > Geb without forcing everyone to change. > > > > > > > > Since Geb is currently tightly coupled to the Selenium WebDriver > model, > > > > a clean path could be an optional geb-direct module under > > > > org.apache.groovy.geb. It would depend on the official Playwright > Java > > > > bindings, add a configuration-driven backend (something like driver = > > > > "playwright" or a playwright { browser = "chromium" } block in > > > > GebConfig), and map Geb’s Navigator/content DSL, Browser, $(), > waitFor, > > > > Page at checkers, and modules onto Playwright Locators and Contexts. > > > > This would let users opt in for the reliability and debugging wins > while > > > > keeping all existing WebDriver/Selenium usage completely untouched as > > > > the default, and advanced features like tracing could hook into Geb’s > > > > existing Reporter system. > > > > > > > > I’d be interested in writing this module if there’s interest from the > > > > community. > > > > > > > > We have a large number of Geb tests in Grails-core and this would > help > > > > them run smoothly in CI. > > > > > > > > James Fredley > > > > VP, Apache Grails > > > > > > > > On 2025/12/31 22:17:56 Jonny wrote: > > > > > I've been doing some thinking about Geb and what things I'd like > to > > > get > > > > > done in the next year. > > > > > > > > > > This isn't so much announcing a formal roadmap as asking folks > for a > > > > > wishlist for Geb. Here are some of the bigger bits that are on my > > > radar. > > > > > Does anyone else have things on theirs? > > > > > > > > > > *Bugfixes* > > > > > > > > > > *Better thread safety in GebTestManager* > > > > > > > > > > https://github.com/apache/groovy-geb/issues/201 and other issues > > > make me > > > > > think that GebTestManager makes some assumptions, particularly > around > > > how > > > > > JUnit lifecycle methods handle tests, that just don't hold in all > > > > cases. My > > > > > hunch is that there are a lot of bugs embedded in this for > parallel > > > > > execution. > > > > > > > > > > Some part of me thinks that the deep answer here is, at least in > > > part, to > > > > > use newer Java concurrency constructs, such as structured > concurrency > > > > > <https://openjdk.org/jeps/453>, but that raises some backward > > > > compatibility > > > > > concerns. > > > > > > > > > > *Projects* > > > > > > > > > > *Testcontainers integration* > > > > > Carl Marcum's work back in October to provide some easy-to-use > > > > integration > > > > > between Geb and Testcontainers seems like a great thing to bring > into > > > the > > > > > Geb project as a first class module. I'd outlined some thoughts on > > > that > > > > > <https://lists.apache.org/thread/k2z0nzdgxrzx2kx429pk6sddtd0r4g5n> > in > > > > > another thread, but how do others feel? > > > > > > > > > > *Release automation* > > > > > I let this lapse a bit, but that may be a bit of a saving grace. > > > Apache's > > > > > Trusted Release Platform > > > > <http://github.com/apache/tooling-trusted-releases> > > > > > seems to be coming along, based on the talk in their Slack channel > > > > > <https://the-asf.slack.com/archives/C049WADAAQG>. > > > > > > > > > > *Bring example projects home* > > > > > We still have a bunch of example projects out in the old Github > org. I > > > > > think those are probably best brought in as included builds in the > > > > main Geb > > > > > repo. This is basically what JMH does with their samples project > > > > > <https://github.com/openjdk/jmh/tree/master/jmh-samples>, and I > > > think it > > > > > would be a bit easier to maintain than scattered repositories. > > > > > > > > > > *Geb 9* > > > > > I'd also like to think ahead to breaking/backwards-incompatible > > > changes > > > > > that we'd like to make. > > > > > > > > > > 1. Require Java 25 to build, compile to Java 11 as target. > Groovy 5 > > > > > requires Java 17 to build, Java 11 as target, so I figured we > > > > should be > > > > > conservative in what we allow, but aggressive in the tooling we > > > use. > > > > > 2. Groovy 5 (and supporting version of Spock, 2.4-groovy-5.0) > > > > > 3. Move from javax -> jakarta > > > > > > > > > > What about BiDi? > > > > > BiDirectional functionality in WebDriver > > > > > <https://www.w3.org/TR/webdriver-bidi/> is something we need to > > > think > > > > about > > > > > how to best expose in Geb. I haven't thought deeply about this, > and it > > > > > frankly seems like the biggest blind spot that needs some light > > > shined on > > > > > it. > > > > > > > > > > What about AI? > > > > > AI-based testing obviously has huge implications for browser > testing. > > > > > https://www.browserstack.com/guide/selenium-with-ai is a good > read > > > > for some > > > > > near-to-hand reaches that Geb could follow or build on. What other > > > things > > > > > should we be considering in this vein? > > > > > > > > > > Thanks for any thoughts. Happy New Year! > > > > > > > > > > Best, > > > > > > > > > > Jonny > > > > > > > > > > > > > > >
