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
>> > > >
>> >
>>
>
