Re: [GEB] Geb in 2026

Since selenium continues to cause Flaky tests on the https://github.com/apach=
e/grails-core builds, I prioritized this.=20

https://github.com/apache/groovy-geb/pull/330 - Add optional geb-direct Playw=
right backend, the PR also links to a grails-core repo branch which can be us=
ed to test this locally. =20

I noticed some dependencies are not the most recent, on master, and I would b=
e 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,
>=20
> I=E2=80=99ve been thinking about ways to bring some of Playwright=E2=80=99s=
 strengths=20
> (BrowserContext isolation, built-in auto-waiting for actionable=20
> elements, strong locator strategies, tracing with=20
> screenshots/DOM/network, video recording, and network interception) into=20
> Geb without forcing everyone to change.
>=20
> Since Geb is currently tightly coupled to the Selenium WebDriver model,=20
> a clean path could be an optional geb-direct module under=20
> org.apache.groovy.geb. It would depend on the official Playwright Java=20
> bindings, add a configuration-driven backend (something like driver =3D=20
> "playwright" or a playwright { browser =3D "chromium" } block in=20
> GebConfig), and map Geb=E2=80=99s Navigator/content DSL, Browser, $(), wait=
For,=20
> Page at checkers, and modules onto Playwright Locators and Contexts.=20
> This would let users opt in for the reliability and debugging wins while=20
> keeping all existing WebDriver/Selenium usage completely untouched as=20
> the default, and advanced features like tracing could hook into Geb=E2=80=
=99s=20
> existing Reporter system.
>=20
> I=E2=80=99d be interested in writing this module if there=E2=80=99s interes=
t from the=20
> community.
>=20
> We have a large number of Geb tests in Grails-core and this would help=20
> them run smoothly in CI.
>=20
> James Fredley
> VP, Apache Grails
>=20
> 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=20
> 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=20
> compatibility
>  > concerns.
>  >
>  > *Projects*
>  >
>  > *Testcontainers integration*
>  > Carl Marcum's work back in October to provide some easy-to-use=20
> 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=20
> <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=20
> 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=20
> 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=20
> 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=20
> 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
>  >
>=20