I haven't complained of slowdowns lately and I'm not sure how much extra build time it takes -- in part because I typically disable it. Until something broke ;-)
Option 1 seems most appealing because it's a step closer to known 3rd party relationships where we just consume a published JAR. But in this case, it's the same repo, and there is no separate release. But the release manager and everyone running the smoketester probably needs to actually build the whole thing. A normal build would consume a published snapshot but a release build would require a non-published non-snapshot. Option 4 I considered gradle caching via ASF Develocity server a bit yesterday. A cache miss could occur sporadically. If the machine/CI/user in question might not have the requirements to build it. Usually that's a non-issue though? I have one machine where it is; I don't know it to be an issue in CI. The cache miss window ought to be on the order of minutes until a CI build dedicated to re-populates the cache runs. I think we could try option 4 with minimal changes to evaluate it. On Wed, Jul 1, 2026 at 2: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 >
