That's correct. That "dependency hell" wouldn't exist. Another aspect is that the integration tests all require their "custom" Quarkus build, which would not be necessary with the apprunner, leading to faster CI.
On Wed, Jul 16, 2025 at 3:42 PM Dmitri Bourlatchkov <di...@apache.org> wrote: > > I was reviewing our Antlr4 dependencies in Spark tests yesterday and realised > that having a running plugin would simplify those tests a lot. > > The current problem is that Quarkus has a different dependency tree from > Spark and combining the two in the same test run requires close attention > to managing dependencies (e.g. we currently pin Antlr4 because of that). > > On the point of ExecFork, etc., I believe that having a custom runner allows > more natural integration with the test code, hence simpler test maintenance. > > Cheers, > Dmitri. > > On 2025/06/16 06:00:00 Pierre Laporte wrote: > > Hello folks, > > > > Bumping this thread following the community sync. > > > > Summary of what was discussed during the sync: > > * We do want to provide Polaris users with a way to run temporary Polaris > > servers during their integration tests. > > * This validates one of the main goals of the Apprunner proposal [1]: be > > usable by Maven projects as well as Gradle projects. > > * The current proposal is based on prior work from Nessie, works with both > > Maven and Gradle, and offers substantial improvements over alternatives > > like testcontainers in CI. > > * Given that a solution based on Gradle ExecFork or Gretty would only serve > > Polaris devs, and would not be usable by users, it does not seems to be a > > good fit for the overarching goal. > > * Some companies who deploy Polaris forbid the use of Docker, which > > prevents the use of testcontainers. > > > > [1] https://github.com/apache/polaris-tools/pull/18/ > > > > Based on these elements, it seems that the current Apprunner plugins should > > be evaluated for integration in the polaris-tools repository. Now before > > calling for a formal review cycle, it would be good to have more feedback > > on the proposal, if certain aspects have not been considered yet. > > > > Wdyt? > > > > -- > > > > Pierre > > > > > > On Mon, Jun 9, 2025 at 1:36 AM Yufei Gu <flyrain...@gmail.com> wrote: > > > > > Sorry for the late reply. > > > > > > Could you clarify why you think that? It is a bit hard to provide answers > > > > to such feedback. > > > > > > What I meant is that the PR [1] seems to provide a lot more than just > > > Polaris related logic, which isn't a concern of the Polaris project. It's > > > fine if it is trying to be a generic gradle plugin to allow start and end > > > a > > > server easily, but it could be somewhere else. Can we focus on the > > > functionalities related to Polaris? > > > > > > For example, here are two options. Both seem to cover our requirements > > > here, while Gretty is easier to use. Can we explore them? > > > > > > 1. ExecFork[2], which runs any Java / shell process in the background > > > 2. Gretty[3], a Jetty / Tomcat dev-server with start/stop tasks > > > > > > > > > [1]. https://github.com/apache/polaris-tools/pull/18 > > > [2]. https://github.com/psxpaul/gradle-execfork-plugin > > > [3]. https://github.com/gretty-gradle-plugin/gretty > > > > > > > > > Yufei > > > > > > > > > On Mon, Jun 2, 2025 at 12:44 AM Pierre Laporte <pie...@pingtimeout.fr> > > > wrote: > > > > > > > On Thu, May 29, 2025 at 7:40 PM Yufei Gu <flyrain...@gmail.com> wrote: > > > > > > > > > I'm supportive if it adds value to both Polaris devs and users. > > > > > > > > > > > > Ok thanks, I am glad we have agreement on the initiative, even if we > > > still > > > > have to discuss the implementation details. > > > > > > > > But, I don't think the Polaris project is in a position to provide a > > > > > generic building infrastructure for integration tests. > > > > > > > > > > > > > Could you clarify why you think that? It is a bit hard to provide > > > answers > > > > to such feedback. > > > > > > > > Can we list use cases the plugin tries to cover? I'd be happy to have a > > > > > discussion session if needed. > > > > > > > > > > > > > I believe I have listed the main high-level features in my first e-mail. > > > > Are you referring to something else? > > > > > > > > Pierre > > > > > > > > >
