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