Good point on QuarkusSparkIT!
Cheers,
Dmitri.
On Thu, Jul 17, 2025 at 6:52 AM Alexandre Dutra wrote:
> 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 o
> Would the runner plugin allow us to move that test back to the
> polaris-runtime-service module?
Yes
On Thu, Jul 17, 2025 at 12:52 PM Alexandre Dutra wrote:
>
> Hi all,
>
> If the runner plugins can save us from the dependency nightmare
> between Spark and Quarkus, imo that's a huge selling p
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 t
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 wrote:
>
> I was reviewing our
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 manag
Thanks for the explanation. I'm OK with moving on with it. The point of
suggesting a separate repo is for the PR owner's convenience and for
follow-up maintainers. Sorry if that didn’t resonate; I'm OK with either
way.
Yufei
On Tue, Jun 17, 2025 at 1:50 AM Pierre Laporte
wrote:
> On Tue, Jun 1
On Tue, Jun 17, 2025 at 1:42 AM Yufei Gu wrote:
> Thanks for the summary.
>
> * 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.
>
> Could you clarify the
Thanks for the summary.
* 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.
Could you clarify the specific feature gaps of ExecFork and Gretty compared
to the p
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
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 gen
On Thu, May 29, 2025 at 7:40 PM Yufei Gu 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 pr
I'm supportive if it adds value to both Polaris devs and users. But, I
don't think the Polaris project is in a position to provide a generic
building infrastructure for integration tests.
Can we list use cases the plugin tries to cover? I'd be happy to have a
discussion session if needed.
Yufei
Just one small note -- we already have tests that require docker to pass.
Note that just summarizing the whole PR to a 7k line Apprunner plugin is a
bit of a stretch. There are actually multiple plugins and multiple DSL to
support many use cases.
A Testcontainers approach could be an option, when Docker images are
available. The tradeoff being that it will require Doc
Thanks for sharing it here.
If all we need is to start a Polaris instance, run the tests, and shut it
down, a 7 k-line Apprunner plugin feels like using a sledgehammer on a
thumbtack. Would a lightweight Testcontainers wrapper, or even a simple
Gradle exec hook would cover the use cases?
Yufei
15 matches
Mail list logo
