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

Reply via email to