I've taken the route of extending solr, the repo checks out solr and builds on top of that. The hard part was to figure out how to use solr test classes and the default location for integration tests, but once there, it is relatively easy. Google for montysolr, the repo is on github. Roman On Oct 16, 2015 10:52 PM, "Upayavira" <u...@odoko.co.uk> wrote:
> > > 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 >
