On Fri, Oct 16, 2015, at 04:00 PM, Ryan Josal wrote: > Thanks for the feedback, forking lucene/solr is my last resort indeed. > > 1) It's not about creating fresh new plugins. It's about modifying > existing ones or core solr code. > 2) I want to submit the patch to modify core solr or lucene code, but I > also want to run it in prod before its accepted and released publicly. > Also I think this helps solidify the patch over time. > 3) I have to do this all the time, and I agree it's better than forking, > but doing this repeatedly over time has diminishing returns because it > increases the cost of upgrading solr. I also requires some ugly > reflection > in most cases, and in others copying verbatim a pile of other classes.
If you want to patch a component, change its package name and fork that component. I have a custom MoreLikeThisHandler in production quite happily like this. I've also done an SVN checkout of Solr, made my code changes there, and then created a local git repo that I can track my own changes for stuff that will eventually get pushed back to Solr. I work concurrently on a number of patches to the Admin UI. They tend to sit in different JIRAs as patches for a few days before I commit them, so this local git repo makes it much easier for me to track my changes, but from the Solr community's perspective, I'm just using SVN. I could easily push this git repo up to github or such if I thought that added value. Then, I regularly run svn update which keeps this checkout up-to-date, and confirm it hasn't broken things. If you wanted to run against a specific version in Solr, you could force SVN to a specific revision (e.g. of the 5x branch) - the one that was released, and git merge your patches into it, etc, etc, etc. Upayavira
