Thanks. Shouldn't we publish a durable/permanent version that we can reference instead of a nightly? That doesn't invalidate the usefulness of a nightly.
On Wed, Sep 2, 2026 at 4:34 PM Christos Malliaridis <[email protected]> wrote: > Alright, after some busy weeks I finally managed to find some time and > complete the changes in https://github.com/apache/solr/pull/4650 where I > extract the UI module into an independent gradle sub-project and make > adjustments to various places. > > I moved out to the module's version catalog the UI module dependencies, so > that we have less clutter during dependency resolution. > > With the changes the devs are now able to pin down to a fixed commit hash > and load the wasmJs distribution for the webapp via nightlies (5MB > download). There is also a flag and a guard for building from source, > especially useful during releases. > > You can find more details in the PR description. I hope these changes > improve significantly the build times for everyone. > > One small side-note: Due to the new gradle properties introduced, I had to > use "build from source" as default fallback, as many CI jobs use their own > gradle.properties and I am not able to update it. Specifically crave and > jenkins jobs need to be updated I think in order to use a predefined commit > (or at least recreate the gradle.properties from > gradle/template.gradle.properties). > > On 2026/07/05 20:15:10 Christos Malliaridis wrote: > > Thanks for the response everyone. According to your feedback it seems > there is consensus for option 1. > > > > There is already a jenkins job that publishes a linux-build of the > standalone client at https://nightlies.apache.org/solr/desktop-ui/, so we > are able to do that quite easy. > > > > With GitHub actions it should be possible to use OS-specific runners for > MacOS and Windows as well. I will have to investigate the distribution > options that also comply with ASF requirements and see how we can consume > them in builds and publications safely, and optionally release the > standalone clients with ease. > > > > I will try to create a PR for review with the necessary changes this > week. Stay tuned. > > > > Thanks again for your quick and replies and insightful opinions. > > > > On 2026/07/01 06:54:03 Christos Malliaridis 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 > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
