Jason, if you look at the policeman jenkins, you will see a lot of failures. (Because of alternate JDK support). You will also see failures for https://ci-builds.apache.org/job/Solr/job/Solr-Test-main-s390x/ because that architecture isn't supported. There are a few other jenkins failures, but the listed ones are problematic enough alone.
As for separating out the project, I'm quite skeptical that it will be maintainable in the long run. The Solr Operator works because it's an entirely different project with code that runs completely independently of Solr (and interacts with a very small amount of Solr APIs). If I'm correct, the UI is not just a standalone application, it will also be the default UI for Solr at some point in the future. If this is the case, I don't really see how we are going to make sure of compatibility and guarantees in a way that us volunteers are going to be able to handle well. I think that people downloading the UI separately to use across multiple Solr instances is going to be a very rare occurrence compared to people using the embedded in-browser version. So IMO we should be developing to favor the later vs the former, and IMO that would mean having the code live in the Solr repo. Obviously that is causing a good amount of grief right now, but I don't think splitting it up is the right solution for that grief. - Houston On Mon, Mar 17, 2025 at 2:46 PM Jason Gerlowski <gerlowsk...@gmail.com> wrote: > Can someone expand on the downsides of having the Kotlin UI code in > the main repo? Or the concrete benefits of separating it out? > > I know there were some CI job failures around the time of the initial > merge, but I haven't noticed it causing issues after that - did I miss > some other discussion where those were covered? > > On Mon, Mar 17, 2025 at 2:47 PM Christos Malliaridis > <c.malliari...@gmail.com> wrote: > > > > I was considering this from the beginning, and I was not aware of the > whole > > stack we were using for building Solr. I thought that the GitHub > workflows > > would be sufficient to guarantee at least the build processes to succeed > in > > all our CI/CD environments, but I was wrong. > > > > Since the UI is generating files that are simply hosted / executed, it > does > > not need all the stack we currently have for Solr. Therefore, it does > make > > sense to use a separate repository. The risk of it getting stale is high > > indeed, but I believe it is still easier to discontinue it if it becomes > > stale before the full replacement of the current UI. > > > > If we decide to move it to a separate project, we would have to guarantee > > somehow the replacement of the current UI once the new UI covers most (if > > not all) features currently present. This was one of the main discussions > > and reasons we tried to integrate it in the current repository. If we can > > maintain its connection to the Solr project, like with the operator, I > > believe it is an acceptable trade-off to move it out. I am personally > not a > > fan of git submodules, but I like the idea of including it as a > dependency > > (not sure what options we would have here). > > > > I also have from the beginning the wish of a separate "release cycle" for > > the development phase of the new UI, probably realized with a combination > > of nightly builds and actual releases in the ASF way, to speed up the > early > > phase and gather user feedback. I believe this would be much easier with > a > > separate repository as well. > > > > And about breaking changes in Solr, the new UI will focus on the v2 API > of > > Solr. Since both are experimental, breaking compatibility is acceptable I > > think. The UI's 1.0 release would also depend on the v2 API of Solr. > > > > On Thu, Mar 13, 2025 at 9:03 PM David Smiley <dsmi...@apache.org> wrote: > > > > > Even if the build & language were well matched, a separate repo with > > > separate releases might be best anyway as it will eventually be > > > independently deployable from Solr as an option. > > > > > > On the other hand, a separate repo may run a risk of getting stale > relative > > > to Solr; its tests not passing if Solr is updated. To mitigate that, I > > > could imagine a dedicated Jenkins job. > > > > > > On Thu, Mar 13, 2025 at 2:54 PM David Smiley <dsmi...@apache.org> > wrote: > > > > > > > Our new UI module has unique/interesting build requirements. And > it's > > > > another language as well. Instead of incorporating it directly into > our > > > > codebase, should it instead be another repo like > > > > https://github.com/apache/solr-ui (doesn't exist yet), as we already > > > have > > > > the solr-operator (written in Go) and solr-sandbox? I didn't think > of > > > this > > > > before because we decided we want Solr to ship with a UI but that > doesn't > > > > actually mean we need to build that UI within Solr. It could be a > > > > dependency. > > > > > > > > We might even consider "git submodule" so a developer can opt-in to > > > > include it if they want to work on it; otherwise the latest release > is > > > > included as a dependency. It's not clear we'd need to bother > integrating > > > > the gradle builds. > > > > > > > > I'm not certain if another repo forces an independent ASF release > process > > > > (e.g. voted on, etc.), as is for the Solr Operator. Wouldn't be a > bad > > > > thing, anyhow. > > > > > > > > ~ David Smiley > > > > Apache Lucene/Solr Search Developer > > > > http://www.linkedin.com/in/davidwsmiley > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
