If we keep it in the same repository, maybe spending some time in simplifying our gradle builds could come in handy. I was challenged to figure out how to add another "core module" that is not just a java library.
To get an idea about the current complexity, after my latest discoveries, our custom logic in render-javadoc.gradle is causing one of the issues in the UI module, but the error is caused by the use of alternative JDKs and the error is thrown in the UI module. Took me some time to trace back the error, which could be fixed by changing a single function. With that said, I think we can reevaluate the current state. The unsupported OS (s390x) is probably something that cannot be fixed, and getting JetBrains supporting a discontinued OS sounds ridiculous. Perhaps we may also reconsider the support / usage of s390x? What other known issues do we have? The fix for the NPE in optimizeTask can be found at https://github.com/apache/solr/pull/3276. This should fix the alternative JDK issues I hope. And thanks a lot to all the folks that opt in to this discussion. :) Best, Christos On Mon, Mar 17, 2025 at 11:31 PM David Eric Pugh <de...@yahoo.com.invalid> wrote: > Yeah, I am a bit suss of having it be in it's own repo. If it's in it's > own repo, folks won't know about it, and it'll struggle to gain traction. > We've gone down the separate repo path with some other efforts, like the > Yet Another Solr Admin UI project. > > Having it not build on various architectures seems just like we need to > put in a bit of work. > > The fact that it's failing on what appears to be a mainframe architecture > doesn't seem too surprise. I'm actually more surprised that Solr runs on > https://en.wikipedia.org/wiki/IBM_System/390! Do we have a active > community of main frame people running Solr???! > > On Monday, March 17, 2025 at 05:13:03 PM EDT, Houston Putman < > hous...@apache.org> wrote: > > 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 > > > > >
