Thank you everyone for the feedback on https://github.com/apache/solr/pull/4650. I will merge the PR soon if there are no other objections.
About the open question of a durable, released version of the web client that we use nightlies for hosting artifacts during development: if you know a better option please let me know. For official releases we are still building from source and not relying on artifacts from nightlies. On Wed, Jul 1, 2026 at 9:54 AM Christos Malliaridis <[email protected]> wrote: > Hello everyone, > > Based on the feedback, the Admin UI's build times have become a problem > and many people are using workarounds to bypass the module's slow build > times. > > To address this issue I am considering a couple paths we could follow > (more proposals are of course welcomed): > > 1. Keep the Admin UI in the same repo but split it from the current build > and only include its artifacts. This would introduce new build workflows > dedicated to the UI module. This may also be a bit tricky, as I am not sure > how to ship artifacts of the Admin UI in Solr builds. It would probably > require us to pin down a commit and use that to fetch artifacts from > somewhere like GitHub(?). > > 2. Split the Admin UI into a separate repository with its own release > cycles. We already have a couple of other solr repositories, and the Admin > UI could be just another one. Integrating it into the existing project as a > dependency is possible, and it would also lean towards the direction of a > headless Solr with optional UI (which some of us are not favoring). That > doesn't mean it has to of course. What's for sure here is that we would > have to go through ASF to request another repo, and everything that comes > with it. > > 3. Disable the wasmJs target build that causes the slowdowns. This would > be the easiest and quickest resolution for now, but would not address the > core issue in the long run, as we want the wasmJs build to replace the > current UI at some point, so we would have to introduce it again or enable > it occasionally. > > 4. Use gradle and kotlin caching features. I believe this is also an > option, but I have some experience with gradle caching that it is often > better left turned off. > > I'd like to address the build slowdowns soon, as it has been a burden to > some of you for too long. Your input and thoughts would help us decide > quicker. > > Best, > Christos >
