Not at all. Thanks for the review, actually!
I think it's a good idea to name it polaris-bin-{version}.tgz or
polaris-{version}-bin.tgz, which indicates that it's a binary
distribution, not a source distribution. Let me make the change.
Yufei
On Wed, May 14, 2025 at 2:31 PM Dmitri Bourlatchkov <di...@apache.org>
wrote:
> Thanks, Yufei! I added some comments in GH despite the "draft" PR status. I
> hope you do not mind :)
>
> Overall, using one distribution archive both for the server and the admin
> tool makes sense to me.
>
> 4. Standardized the binary distribution package naming to
> polaris-{version}.tgz and polaris-{version}.zip, following common
> conventions used by other projects (e.g., spark-3.5.5-bin-hadoop3.tgz).
>
>
> Would it make sense to use archive names like polaris-1.0.0-bin.tgz (to
> follow Spark's example closer)?
>
> Thanks,
> Dmitri.
>
> On Wed, May 14, 2025 at 2:32 PM Yufei Gu <flyrain...@gmail.com> wrote:
>
> > Hi Folk,
> > Thanks a lot for the discussion. Here is the PR(
> > https://github.com/apache/polaris/pull/1589) to merge the binary
> > distribution while still keeping module polaris-quarkus-admin and
> > polaris-quarkus-server separately.
> >
> > *What’s included in the PR:*
> >
> > 1. Introduced a new module that combines binary distribution for both
> > Admin Tools and Server. Please note that source and jar are still
> > separated. Please refer to my original email for the motivation behind
> > this
> > change.
> > 2. Removed the now-redundant run-scripts module.
> > 3. Consolidated the README to reflect the unified binary distribution.
> > 4. Standardized the binary distribution package naming to
> > polaris-{version}.tgz and polaris-{version}.zip, following common
> > conventions used by other projects (e.g.,
> spark-3.5.5-bin-hadoop3.tgz).
> >
> > *TODOs*:
> >
> > 1. Consolidate LICENSE and NOTICE files from both Admin Tools and
> > Server.
> > 2. Remove the distribution tasks in each of the original modules.
> >
> > The PR is technically ready, but I plan to wait until the 0.10 release is
> > finalized to avoid disrupting the release process.
> >
> >
> > Yufei
> >
> >
> > On Tue, May 6, 2025 at 9:31 AM Yufei Gu <flyrain...@gmail.com> wrote:
> >
> > > Other than duplicated downloads for shared jars, the big problem is
> that
> > > the configuration difference between admin tool and server may cause
> > server
> > > issues, e.g., the admin tool may bootstrap a realm in a wrong database.
> > >
> > > Let's move them into the same distribution package first. Then we can
> > > consider merging the modules, as we discussed the separation makes the
> > > development and release unnecessary cumbersome.
> > >
> > > Yufei
> > >
> > >
> > > On Tue, May 6, 2025 at 5:57 AM Dmitri Bourlatchkov <di...@apache.org>
> > > wrote:
> > >
> > >> Thanks for the clarification, JB!
> > >>
> > >> Packaging both the server and the admin tool in the same distribution
> > >> (archive) is certainly a good idea.
> > >>
> > >> Cheers,
> > >> Dmitri.
> > >>
> > >> On Tue, May 6, 2025 at 2:33 AM Jean-Baptiste Onofré <j...@nanthrax.net>
> > >> wrote:
> > >>
> > >> > Hi
> > >> >
> > >> > We can see two aspects here:
> > >> > - the merge of the applications
> > >> > - gather applications in one package/distribution (tar.gz/zip)
> > >> >
> > >> > I'm in favor of the later because:
> > >> > - admin and server distributions share 80% of the same artifacts
> > >> > - users have to download to "big" packages
> > >> >
> > >> > We should keep the Quarkus applications separated but we can gather
> > >> > both in one distribution, with this kind of layout:
> > >> > - admin/run.sh
> > >> > - admin/lib/boot
> > >> > - admin/lib/main
> > >> > - server/run.sh
> > >> > - server/lib/boot
> > >> > - server/lib/main
> > >> > - lib/common
> > >> > I don't see why it could not work with Quarkus (I already did
> > >> > something similar for other Quarkus application, using maven
> assembly
> > >> > plugin).
> > >> >
> > >> > Regards
> > >> > JB
> > >> >
> > >> > On Tue, May 6, 2025 at 2:54 AM Dmitri Bourlatchkov <
> di...@apache.org>
> > >> > wrote:
> > >> > >
> > >> > > Hi Yufei,
> > >> > >
> > >> > > Please note that the admin tool is a CLI application, while the
> > >> quarkus
> > >> > > "server" is a REST application.
> > >> > >
> > >> > > How do you envision supporting both CLI and REST API in the same
> > >> module?
> > >> > >
> > >> > > Thanks,
> > >> > > Dmitri.
> > >> > >
> > >> > > On Mon, May 5, 2025 at 2:49 PM Yufei Gu <flyrain...@gmail.com>
> > wrote:
> > >> > >
> > >> > > > Hi folks,
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > I’d like to propose merging the polaris-quarkus-admin and
> > >> > > > polaris-quarkus-server modules. While modularization can bring
> > >> benefits
> > >> > > > like clearer separation of concerns, in this case, the split
> seems
> > >> to
> > >> > cause
> > >> > > > more friction than value. Here’s why I think merging makes
> sense:
> > >> > > >
> > >> > > > 1. Improved usability: Users can find all tools in one place,
> > >> > making it
> > >> > > > easier to use and onboard. Just try out the new 0.10.0-beta
> > >> binary
> > >> > > > releases, you will find out the inconvenience of the
> > separation.
> > >> > Plus, I
> > >> > > > don’t think anyone will use the admin tool without Polaris
> > >> server.
> > >> > We
> > >> > > > don't have to merge the module to archive a single binary
> > release
> > >> > > > package,
> > >> > > > but merging two modules will make it really easy.
> > >> > > > 2. Simpler development: The split has led to small utility
> > >> modules
> > >> > like
> > >> > > > “test-common” and “run-script” that only exist to bridge the
> > >> > separation.
> > >> > > > Merging the two will reduce duplication and save time for
> > >> everyone.
> > >> > > > 3. Easier releases: We’d no longer need to generate separate
> > >> > > > LICENSE/NOTICE files or maintain two binary packages.
> > >> > > >
> > >> > > >
> > >> > > > I’ve talked to folks like JB and Prashant about this offline,
> and
> > >> the
> > >> > > > feedback so far has been positive.
> > >> > > >
> > >> > > >
> > >> > > > If there are no objections, I’ll file a PR to merge the two and
> > aim
> > >> to
> > >> > > > package them together starting with the 1.0 release.
> > >> > > >
> > >> > > >
> > >> > > > Yufei
> > >> > > >
> > >> >
> > >>
> > >
> >
>
