Hi all, If the runner plugins can save us from the dependency nightmare between Spark and Quarkus, imo that's a huge selling point.
An example: the QuarkusSparkIT test lives in its own module (!), precisely because of dependency issues. Would the runner plugin allow us to move that test back to the polaris-runtime-service module? If yes, that would be awesome. Thanks, Alex On Thu, Jul 17, 2025 at 11:14 AM Robert Stupp <sn...@snazy.de> wrote: > > 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 > > > > > > > > > > > >
