This is a false claim. My patch logs a warning.
my apologies, i misread the patch and thought it would only warn on first usage. It doesn't change the fundemental issue however...
Hoss, you apparently have a black or white view of things
I absolutely consider this issue to be black/white.
However I do think that if the Solr user/packager realized that Velocity is not used in their setup (perhaps using Solr in an embedded fashion) and if Solr can gracefully work without it for the rest of Solr that doesn't need it, then it should run without it.
the problem with that philosophy is that it completely breaks the "contract" we make with our users – novices and plugin writers – about what they can/can't expect to be in a basic solr installation.
if someone repackages solr to not include something that is considered a "core" feature/dependency, then that installation is absolutely, 100% broken, and we should not go out of our way to help that packager/installer mask the broken nature.
It is broken not only because whatever out of the box feature we advertise as being available no longer works for novice users who may try to use those features, but it is broken because anyone trying to write a plugin can no longer say "all you need to load my plugin jar is this <lib.../> directive, because all of the dependencies are already core solr dependencies"
if VelocityWriter is a core feature (and as of now it is) then velocity is a core dependency and we should not jump through this hoop to deal with the possibility of velocity dependencies being missing any more then we should jump through hoops to deal with the possibility that commons-io, or commons-fileupload is missing – in either case, the system is not a fully functional solr installation as documented, and we should not hide that from users until they actually try to use a documented feature and get a failure.
If someone wants to bastardize a solr installation to remove core dependencies we should not be making it easier on them just because it only means changing a few line of code – that just hamstrings us with an expectation that we can never use that dependency in any other ways in the core. Either we rip that dependency out (making it a plugin instead of a core feature) or we let the bastardizers patch the affected files themselves.
Any middle ground hurts our users by making it impossible to know what features will/won't work in any given install, and hurts development by hindering when/how we can use libraries we've already said are core dpendencies.