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