Thanks for that context, James. That's all helpful! I had thought that testcontainers had some Windows support ( https://java.testcontainers.org/supported_docker_environment/windows/), though there are limitations that might prevent it from working for our case.
I agree that the best path forward would be for Carl to start a branch working on rolling it into the repository, as outlined above. Carl, if there's anything I can do to make one of my suggestions clearer or otherwise help unstick something, please let me know. Best, Jonny On Wed, Dec 31, 2025 at 10:56 PM James Daugherty <[email protected]> wrote: > @Carl, I want to say thank you for doing this initial work. I'm > thrilled you've followed up on our initial discussions. We originally > set out to make the Geb configuration easier and moving this > functionality into Geb itself is a worthwhile effort - especially if > there's support by the project. I'd rather the Grails plugin simply > be a wrapper around upstream functionality if at all possible and it > seems like Jonny likes the idea too so it's worth pursuing. > > @Jonny Concerning the GrailsContainerGebExtension, I copied the Geb > extension code when I created the Grails spock extension since there > wasn't an easy way to invoke that code and I needed to perform > additional steps for the container setup. Making it more extensible > is definitely the right solution here. There's no reason to > duplicate. > > Concerning the property configuration; we tried several approaches. > Initially it was annotation based configuration, then system > properties, and finally we started supporting the GebConfig file > itself. @Mattias & @Jonas substantially evolved my initial work on > using a spock extension. Specifically, Jonas made substantial > improvements to it and will likely have more feedback here. I'm > including them both on this email chain for their thoughts. > > Concerning the examples, I'm assuming those examples are effectively > functional/end-to-end tests for Geb. While I'm not a commiter on the > Geb project, I would strongly advise you to place the examples in the > main repository. When we merged the Grails functional tests into the > main repo, it helped accelerate our testing and helped ensure stable > releases. As we have refactored, it's been much easier to make larger > changes. > > Concerning using testcontainers, one downside is there isn't really a > windows equivalent. If people are using Geb to drive browsers on > windows that need can't exactly be met. WIth that said, windows > machines can run linux containers, and the assumption is the browser > is similar enough on a different OS that it doesn't matter. > > @Jonny for the spock vs testcontainers, the current implementation is > tied to spock. I'm not sure if that factors into a top level or an > integration module - I'm not as familiar with how Geb's project is > structured. > > Regards, > James > > On Wed, Dec 31, 2025 at 6:43 PM Carl Marcum <[email protected]> > wrote: > > > > Hi Jonny, > > > > Thanks for looking at this. > > > > "First, would it make sense for this to simply be a submodule of the Geb > repository?" > > > > Yes, I was thinking it could be released as a library like geb-spock, > geb-junit5, etc. > > > > "made me wonder if we need to modify the GebExtension, or create some > more extensible base class of it so that geb-containers doesn't have to do > so much redundant work. That should, in principle, allow > GrailsContainerGebExtension to be simplified. Perhaps it could be removed > altogether, if we get the design right. This might also be the kind of > thing that would be easier to see (using IDE tooling) and maintain if > geb-containers was part of the main Geb repository." > > > > Definitely something to explore. > > > > On the example application, Yes it was just meant to be a happy-path > test example but you have a good point about the separate JVM. > > > > I'm working on implementing that now. > > > > I like the idea of having the example projects in the repo for Geb. I > think it makes it easier to follow the current project version than having > something separate go update. > > > > "I'd be inclined to build it as a new submodule of the `integration` > submodule (geb-testcontainers), though maybe it should be a top-level > module like geb-spock. Open to persuasion there." > > > > I was originally thinking of under modules since it's a library, but > being under integration now makes sense to me. > > > > "Eliminate the need for any redundant code within the codebase (like > GrailsContainerGebExtension, above); look at modifying, composing, or > subclassing existing extension points if necessary." > > > > Once we get this started, the Grails team may have some thoughts as well > as they did what they had to do from the outside. > > > > "Consider how we might remove the need for the redundant bits of the > grails.geb plugin. For example, I see the properties like > grails.geb.atCheckWaiting. I'm pretty sure those just map down to the geb > properties of the same name. Is there something we'd need to do to surface > them so that folks would be interacting with Geb directly? I'm not looking > to break the grails-geb implementation, just considering if there's > something we could do at a more fundamental level that would make > integration of Geb simpler and easier, and remove the need for the grails > project to maintain as much of that code. Maybe the grails.geb properties > are a bad example because they don't require more code (I haven't dug into > that implementation), but hopefully you get the idea." > > > > I have been working on bringing some settings from GebConfig into > WebDriverContainerHolder as I've needed them where Grails did not, or in > some cases they have started to move in that direction also instead of > system properties and I've followed that lead. More can be done here. > > > > Maybe the next step could be create a geb-testcontainers branch to work > in and I can start getting the code pushed in and a build working and go > from there? > > > > Best regards, > > > > Carl > > > > On 12/30/25 11:15 AM, Jonny wrote: > > > > Hey, Carl! Late in replying, but color me interested! > > > > I know testcontainers make browser setup a lot easier and less platform > constrained; in particular, it can become easier to use the same > configuration on CI and your local environment. I remember James Fredley > pointing them out to me during a Geb workshop at Community Over Code > earlier this year. > > > > I've been poking around at the implementation. I have a few thoughts. In > no particular order: > > > > First, would it make sense for this to simply be a submodule of the Geb > repository? We already publish integrations (via Gradle plugins) for things > like SauceLabs and BrowserStack. I still need to get those working properly > (changed maven coordinates has created a bit of faff with the Gradle plugin > portal), but it seems like the sort of thing that would be relevant to > include "out of the box". > > > > Second, these comments on GrailsContainerGebExtension.groovy: > > > > > ContainerGebSpec cannot be a geb.test.ManagedGebTest ManagedGebTest > because it would cause the test > > > manager to be initialized out of sequence of the container management. > > > Instead, we initialize the same interceptors as the > geb.spock.GebExtension GebExtension does. > > > > made me wonder if we need to modify the GebExtension, or create some > more extensible base class of it so that geb-containers doesn't have to do > so much redundant work. That should, in principle, allow > GrailsContainerGebExtension to be simplified. Perhaps it could be removed > altogether, if we get the design right. This might also be the kind of > thing that would be easier to see (using IDE tooling) and maintain if > geb-containers was part of the main Geb repository. > > > > Third, I noticed that in your example, the example test runs the app > under test inside the same JVM as the Geb test itself. That's not "wrong" > or anything, but it did strike me as counter-intuitive, which forced me to > think about why. Part of it was just that when I started the test in a > debugger and attached a breakpoint to the test, the web application > couldn't independently respond to requests. Sometimes that's fine enough, > if all you want is the Geb test to run quickly through some "happy path" > tests, which is a valid use case. However, if you want to manually poke at > your webapp, take thread dumps, or otherwise mess with it while Geb tests > are running, you probably want it in its own process. Given that > testcontainers are all about isolating and abstracting things away, it > seemed sensible that the example would create that kind of separation > between the webapp under test and the Geb test itself. > > > > Some time ago, I'd talked with Sergio about bringing the various > geb-example repositories into the geb repo itself (such as > https://github.com/geb/geb-example-maven). Other projects, like jmh and > its jmh-samples, do this and it seems more manageable to me. We could do > something like this with your example project, especially if we did publish > geb-test-containers as its own module. > > > > Would you have any interest in taking this further? Here are some broad > brushstrokes ideas of what I'd like to see in a PR into the Geb repository > that supported this: > > > > I'd be inclined to build it as a new submodule of the `integration` > submodule (geb-testcontainers), though maybe it should be a top-level > module like geb-spock. Open to persuasion there. > > Eliminate the need for any redundant code within the codebase (like > GrailsContainerGebExtension, above); look at modifying, composing, or > subclassing existing extension points if necessary. > > Consider how we might remove the need for the redundant bits of the > grails.geb plugin. For example, I see the properties like > grails.geb.atCheckWaiting. I'm pretty sure those just map down to the geb > properties of the same name. Is there something we'd need to do to surface > them so that folks would be interacting with Geb directly? I'm not looking > to break the grails-geb implementation, just considering if there's > something we could do at a more fundamental level that would make > integration of Geb simpler and easier, and remove the need for the grails > project to maintain as much of that code. Maybe the grails.geb properties > are a bad example because they don't require more code (I haven't dug into > that implementation), but hopefully you get the idea. > > > > Thanks again for putting this together. Integrations with popular > testing tools like testcontainers is exactly what Geb needs. > > > > Best, > > > > Jonny > > > > On Tue, Oct 21, 2025 at 5:48 PM Carl Marcum <[email protected]> > wrote: > >> > >> Hi All, > >> > >> After seeing how Grails was testing with Geb and Testcontainers using > >> their Grails Geb Plugin [1]. > >> I had some non-Grails projects to test with Geb so I created a > >> standalone Geb-Container library [2] based on that plugin. > >> I modified it some to take out the Grails dependencies and it has worked > >> out well. > >> I also setup a sample project for trying it out [3]. > >> > >> My thought was that it would make a good addition to Geb as a module and > >> I wanted to get the your thoughts. > >> > >> > >> [1] https://github.com/apache/grails-core/tree/7.0.x/grails-geb > >> [2] https://github.com/cbmarcum/geb-container > >> [3] https://github.com/cbmarcum/geb-container-sample > >> > >> Best regards, > >> Carl >
