That seems like a win Walter
> On Jul 3, 2026, at 6:00 PM, James Fredley <[email protected]> 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 > >
