What about (not tried) pulling down an official Docker build and adding your stuff to that? https://hub.docker.com/_/solr/
Regards, Alex. ---- Newsletter and resources for Solr beginners and intermediates: http://www.solr-start.com/ On 30 July 2016 at 03:03, Demian Katz <demian.k...@villanova.edu> wrote: >> I wouldn't include Solr in my own project at all. I would probably >> request that the user download the binary artifact and put it in a >> predictable location, and configure my installation script to do the >> download if the file is not there. I would strongly recommend taking >> advantage of Apache's mirror system for that download -- although if you >> need a specific version of Solr, you will find that the mirror system >> only has the latest version, and you must go to the Apache Archives for >> older versions. >> >> To reduce load on the Apache Archive, you could place a copy of the >> binary on your own download servers ... and you could probably greatly >> reduce the size of that download by stripping out components that your >> software doesn't need. If users want to enable additional >> functionality, they would be free to download the full Solr binary from >> Apache. > > Yes, this is the reason I was hoping to use some sort of dependency > management tool. The idea of downloading from Apache's system has definitely > crossed my mind, but it's inherently more fragile than using a dependency > manager (since Apache is at least theoretically free to change their URL > structure, etc., at any time) and, as you say, it seemed impolite to direct > potentially heavy amounts of traffic to Apache servers (especially when you > consider that every commit to my project triggers one or more continuous > integration builds, each of which would need to perform the download). > Creating a project-specific mirror also crossed my mind, but that has its own > set of problems: it's work to maintain it, and the server hosting it needs to > be able to withstand the high traffic that would otherwise be directed at > Apache. The idea of a theoretical dependency management tool still feels more > attractive because it adds a standard, unchanging mechanism for obtaining > specific versions of the software and it offers the possibility of local > package caching across builds to significantly reduce the amount of HTTP > traffic back and forth. Of course, it's a lot less attractive if it proves to > be only theory and not in fact practically achievable -- I'll play around > with Maven next week and see where that gets me. > > Anyway, I don't say any of that to dismiss your suggestions -- you present > potentially viable possibilities, and I'll certainly keep those ideas on the > table as I plan for the future -- but I thought it might be worthwhile to > share my thinking. :-) > >> I once discovered that if optional components are removed (including >> some jars in the webapp), the Solr download drops from 150+ MB to about >> 25 MB. >> >> https://issues.apache.org/jira/browse/SOLR-6806 > > This could actually be a separate argument for a dependency-management-based > Solr structure, in that you could create a core solr package with minimum > content that could recommend a whole array of optional dependencies. A script > could then be used to build different versions of the download package from > these -- one with just the core, one with all the optional stuff included. > Those who wanted some intermediate number of files could be encouraged to > manually create their desired build from packages. > > But again, I freely admit that everything I'm saying is based on experience > with package managers outside the realm of Java -- I need to learn more about > Maven (and perhaps Ivy) before I can make any particularly intelligent > statements about what is really possible in this context. :-) > > - Demian
