*> Users already get two artfacts: one for the server, another for the admin tool. Each one has a specific and distinct purpose. I personally do not see a usability problem here.* I definitely see a usability problem here. Consider that every command in the CLI may have a distinct purpose but we ship a single script. It seems user-antagonistic to split up the admin tool and the service when they're meant to be used together and the configs are always expected to be matching (for a given admin tool / service invocation pair).
This is different from a "real" client like the python client, which I think could reasonably get its own artifact. It doesn't require any configuration matching the server's configuration and the user persona is certainly different from the user persona for the admin tool + server. *> As for developers, ... Small modules actually help with proper separation of concerns in code, I believe. Plus, gradle is well equipped for building many small modules.* As a developer I have found the proliferation of small modules to reduce my productivity. Dependency management has become much more complicated, and we've had to introduce abstractions like QuarkusFeaturesConfiguration to glue our modules together. An interesting piece of trivia: we had ~10 modules at the time of release 0.9.x in January and we have ~31 today. *> I do not really see how unifying code simplifies LICENCE/NOTICE* Wouldn't unifying the modules mean that they necessarily have the same dependencies whereas today they could in theory drift apart? On Mon, May 5, 2025 at 6:24 PM Dmitri Bourlatchkov <di...@apache.org> wrote: > These applications are built by Quarkus using different plugins (CLI vs. > REST API). > > The output of a module is normally one jar, hence only one main class. > > If we were to add custom code to run both CLI and REST API from the same > jar, we'd be losing most of the benefits of Quarkus plugins that were > already made to help developers. > > I think trying to unify these modules is akin to fitting a round peg into a > square hole... It can work only if there are sufficient gaps ;) > > 1. Improved usability: Users can find all tools in one place [...] > > > This point seems to be conflating users and developers. Users already get > two artfacts: one for the server, another for the admin tool. Each one has > a specific and distinct purpose. I personally do not see a usability > problem here. > > 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. > > > As for developers, modern IDEs can find classes easily. I personally > believe that module isolation improves clarity for developers in this case. > Code duplications can be removed with some additional refactoring. > > Small modules actually help with proper separation of concerns in code, I > believe. Plus, gradle is well equipped for building many small modules. > > 3. Easier releases: We’d no longer need to generate separate > LICENSE/NOTICE files or maintain two binary packages. > > > I do not really see how unifying code simplifies LICENCE/NOTICE. We still > have to keep track of the same set of dependencies and update them for > every release, and this is the hard part. Where we put the mentions (after > we figure out what needs to be mentioned) does not make much of a > difference, IMHO. > > Cheers, > Dmitri. > > On Mon, May 5, 2025 at 9:07 PM Eric Maynard <eric.w.mayn...@gmail.com> > wrote: > > > I don’t really understand the question. Are you asking how a single > gradle > > module can contain a CLI and a service? The naive way is just to have two > > different main classes but perhaps you mean something else? > > > > In Dropwizard this was seemingly the standard way of doing things, as you > > could register one or more Command in the Application where you > registered > > REST resources. > > > > On Mon, May 5, 2025 at 5:55 PM 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 > > > > > > > > > >
