Re: [GEB] Geb in 2026

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
 >