Re: [DISCUSS] Solr Admin UI Build Slowdowns

[Christos Malliaridis <ma...@apache.org>]

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: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org

Re: [DISCUSS] Solr Admin UI Build Slowdowns

[Christos Malliaridis <ma...@apache.org>]

I am aware that the content on the nightlies is not permanent, and
therefore I am open for any alternatives. What other options do we have
that do not require us to go through the ASF release process? I would also
not bother much with the current experimental state of the UI. The wasmJs
build is something that we will probably never ship separately from Solr,
and the desktop build is something that we currently publish only on
nightlies because there is no actual release candidate ready (we are far
from a useful client).



On Thu, Sep 3, 2026 at 12:48 AM David Smiley <ds...@apache.org> wrote:

> 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 <
> malliaridis@apache.org>
> 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: dev-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: dev-help@solr.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >
>

Re: [DISCUSS] Solr Admin UI Build Slowdowns

[David Smiley <ds...@apache.org>]

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 <ma...@apache.org>
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: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>