RE: Installing Solr as a dependency

[Demian Katz <de...@villanova.edu>]

Thanks -- another interesting possibility, though I suppose the disadvantage to this strategy would be the dependency on Docker, which could be problematic for some users (especially those running Windows, where I understand that this could only be achieved with virtualization, which would almost certainly impact performance). Still, another option to put on the table!

- Demian

-----Original Message-----
From: Alexandre Rafalovitch [mailto:arafalov@gmail.com] 
Sent: Friday, July 29, 2016 8:02 PM
To: solr-user
Subject: Re: Installing Solr as a dependency

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 <de...@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