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