Ryan, >From a "solr-user" perspective :) I would advise against forking Solr. Some of our consulting business is "people who forked Solr, need to upgrade, and now have gotten themselves into hot water."
I would try, in the following order 1. Creating a plugin (sounds like you can't do this) 2. Submitting a patch to Solr that makes it easier to create the plugin you need 3. Copy-pasting code to create a plugin. I once had to do this for a highlighter. It's ugly, but its better than forking. 4.... 999. Hiring Yonik :) 1000. Forking Solr 999 a prereq for 1000 :) Even very heavily customized versions of Solr sold by major vendors that staff committers are entirely plugin driven. Cheers -Doug On Fri, Oct 16, 2015 at 3:30 PM, Alexandre Rafalovitch <arafa...@gmail.com> wrote: > I suspect these questions should go the Lucene Dev list instead. This > one is more for those who build on top of standard Solr. > > Regards, > Alex. > > ---- > Solr Analyzers, Tokenizers, Filters, URPs and even a newsletter: > http://www.solr-start.com/ > > > On 16 October 2015 at 12:07, Ryan Josal <r...@josal.com> wrote: > > Hi guys, I'd like to get your tips on how to run a Solr fork at my > > company. I know Yonik has a "heliosearch" fork, and I'm sure many others > > have a fork. There have been times where I want to add features to an > > existing core plugin, and subclassing isn't possible so I end up copying > > the source code into my repo, then using some crazy reflection to get it > to > > work. Sometimes there's a little bug in something and I have to do the > > same thing. Sometimes there's something I want to do deeper in core Solr > > code that isn't pluggable and I end up doing an interesting workaround. > > Sometimes I want to apply a patch from JIRA. I also think forking solr > > will make it easier for me to contribute patches back. So here are my > > questions: > > > > *) how do I properly fork it outside of github to my own company's git > > system? > > *) how do I pull new changes? I think I would expect to sync new changes > > when there is a new public release. What branches do I need to work > > with/on? > > *) how do I test my changes? What part of the test suites do I run for > > what changes? > > *) how do I build a new version when I'm ready to go to prod? This is > > slightly more unclear to me now that it isn't just a war. > > > > Thanks, > > Ryan > -- *Doug Turnbull **| *Search Relevance Consultant | OpenSource Connections <http://opensourceconnections.com>, LLC | 240.476.9983 Author: Relevant Search <http://manning.com/turnbull> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
