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 proposed plugin? A concrete test case or example would help validate
the difference.

On a separate note, would it make sense to host this plugin in a standalone
repo? From the PR, it appears to be quite self-contained.

Yufei


On Sun, Jun 15, 2025 at 11:00 PM Pierre Laporte <pie...@pingtimeout.fr>
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
> > >
> >
>

Reply via email to