Re: [GEB] Geb in 2026

That seems like a win

Walter

> On Jul 3, 2026, at 6:00=E2=80=AFPM, James Fredley =
<[email protected]> wrote:
>=20
> Hey folks,
>=20
> I=E2=80=99ve been thinking about ways to bring some of Playwright=E2=80=99=
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.
>=20
> 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 =3D =
"playwright" or a playwright { browser =3D "chromium" } block in =
GebConfig), and map Geb=E2=80=99s 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=E2=80=99s existing Reporter system.
>=20
> I=E2=80=99d be interested in writing this module if there=E2=80=99s =
interest from the community.
>=20
> We have a large number of Geb tests in Grails-core and this would help =
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 =
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
> >