Of the options, I would lean towards option 1. I feel strongly that moving it to separate repo means it won’t build traction and gain more contributors to it (the pattern we’ve seen with other attempts a new Solr UI).
> On Jul 1, 2026, at 5:37 AM, Jan Høydahl <[email protected]> wrote: > > Thanks for bringing this up. > > I lean towards option 1. Split the build. It would give us much of the same > process > as with lucene. It is a pinned dependency in the main build, but it is > possible to point > it to a local snapshot somehow - if we find a similar way of doing that for > the UI. > > I guess the risk is low. Only in major releases will we make breaking REST > API changes > that would fully break the UI. Adding UI features could be done in smaller > faster > iterations in the more focused UI build. > > I don't know either what the artifacts would look like and where to publish > them. One > option is to add them as new versioned release artifacts in > downloads.apache.org, > and then we could start shipping the standalone AdminUI app as well? > > Jan > >> 1. juli 2026 kl. 08:54 skrev Christos Malliaridis <[email protected]>: >> >> 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 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.
