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 > >
