Make UI module independent sub-project

[malliaridis]

See discussion https://lists.apache.org/thread/onc0zyyp8tjoj3fdg3bmpnh9cqsgjhy6

Description

We have noticed slow build times and problems related to the Admin UI module that requires developers to disable the module entirely, which led to other dependency resolution issues.

This PR attempts to separate the module from the rest of the project by making it an independent sub-project.

Solution

The approach that was picked is a completely independent gradle project. Some important changes:

• Dependency resolution for the UI module is happening separately from the rest of the project, so dependencies are not aligned
• Many build configurations that apply to most solr modules are removed, allowing the UI module to use simpler builds
• The exclusion of many plugins and configurations means there are no default checks included
• [TODO further changes]

We should evaluate before merging which of the configurations or routines we want to keep and apply to this module as well.

The module is no longer included as a configuration or task dependency as implemented before. Instead, the webapp now has to fetch the UI artifacts from [TODO].

Developers can call ./gradlew dev -Psolr.ui.buildFromSource=true to build the UI module locally and include the artifacts from the current state, or alternatively define a commit (and optionally a checksum for validation) in the gradle/solr-ui.properties to download the UI bundle from the nightlies server.

A guard has been added for specific release tasks that prevents using a nightly build artifact, and forces the UI to be built from source.

Tests

Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem.

Checklist

Please review the following and check all that apply:

• I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
• I have created a Jira issue and added the issue ID to my pull request title.
• I have given Solr maintainers access to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation)
• I have developed this patch against the main branch.
• I have run ./gradlew check.
• I have added tests for my changes.
• I have added documentation for the Reference Guide
• I have added a changelog entry for my change

[dsmiley]

I think we should use the same gradle wrapper, at least.

It's not clear how new master Solr build acquires the UI artifacts to serve.

[dsmiley]

woah; can't we re-use the gradle wrapper of the parent project?

[malliaridis]

I know it is possible through the terminal by using ./gradlew -p ui/ [some-task], but I haven't figured out yet how to let IntelliJ know that it should use the wrapper from the root project. Since it is no longer in the settings.gradle.kts listed as included module, it is not loaded in the IDE, nor by gradle.

Once I figure that out I will also update the README.md (documentation) to include instructions what to do to load the module correctly.

This is why it is still a draft.

[malliaridis]

It's not clear how new master Solr build acquires the UI artifacts to serve.

It is not clear because it is not solved yet. 🫤

I haven't figured it out yet how to do that the proper way (e.g. where can we publish artifacts, how to build it in advance for a release, how to retrieve artifacts?). I wanted to look into the solution we use for lucene and see if it can be reliably used for the UI in releases as well.

Another thing that I am unsure is all the licensing stuff. We would have to treat it completely different. I believe the best option we have is to display open-source licenses in the UI somewhere, but for that we would have to retrieve them first.

All the project configurations are removed, which is both a blessing and a curse as you can see.

If you have any input on how to solve specific issues, feel free to leave a comment or commit to this PR. Happy to colaborate on this one. :)