I guess this discussion is becoming bigger than just the merging of admin and server modules.
I'd like to propose staying on the original narrow topic, so please share concrete ideas about handling CLI and REST applications in the same module under Quarkus. It may be possible, I never tried it personally, though. As to the bigger topic of (re-)organizing source modules in general. I actually wanted to open a discussion about that as well, specifically with the NoSQL Persistence in mind. I suppose it may be worth doing that in a new dev email thread. WDYT? Thanks, Dmitri. On Mon, May 5, 2025 at 9:39 PM Eric Maynard <eric.w.mayn...@gmail.com> wrote: > *> 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 > > > > > > > > > > > > > > >
