: 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.
This seems to ignore one of the key points that David/Christos suggested: that we still include the new UI "artifact" in releases of solr, as a *dependency*. In essence: use a new repo to decouple the existing Slr build process from the build process of the UI with all of it's build time weirdness and special dependencies -- like aparently needing chome installed to run tests -- that can cause problems with the greater overall Solr build. FWIW: In addition to the things that aparently cause problems for alternate JDKs in jenkins, i would like to point out that it seems incredibly silly that my few year old linux laptop has a GLIBC which is good enough for running bleeding edge JDKs, but aparently not good enough to build the Solr UI -- Which means i basically just don't bother trying to build Solr's `main` branch anymnore. (and it means a bunch of misc jenkins jobs can sporadically fail just because the worker node the job was assigned to also has happens to be running an older kernel) I'm far more worried about the Solr *java* code being adequately tested on a large variety of JVMS & architectures then i am about treating the build requirements of the UI as the minimum requirements for the *ENTIRE* Solr build process. If moving the new UI to it's own repo and only "building" the new UI on limited hardware, and then depending on the UI artifacts in the Solr releases, gets us back to the point of being able to actually run the Solr gradle build reliably on any platform that has a usable JDK -- that sounds pretty damn good to me. Having said that though: I don't think we actaully need a completely independent repo, for the same reasons i never thought it made sense to create any of the other repos we now have... https://lists.apache.org/thread/d2qw8jzxq65z6n541vmyrpbt171y84cy ...i see no reason why we can't just "git mv" the new UI module into a new top level directory of the existing solr git repo, decoupling it's build system from the "main" gradle build, and treat it as if it *were* a seperate repo w/artifacts we consume -- but w/the added benefit of being able to branch & tag both solr and the UI in lock step. - The "main" solr build can keep working on any architecture where java works, and be agnostic to the UI and it's special needs - The UI build can do whatever it wants, and depend on whatever it wants, w/o affecting anyone that doesn't care about the UI - a subset of our CI builds -- that are known to supply everything needed by the UI -- can build both in synchronicity (as can the RM) ...and we leave the door open down the road for a "git mv" to put the UI back into the main solr build hierarchy as a module (if/when we're satisfied that it plays nicely w/everything else in our build, and it's external requirements aren't too onerous for joe-blow developers) -Hoss
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
