[ 
https://issues.apache.org/jira/browse/SOLR-14915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214446#comment-17214446
 ] 

Ishan Chattopadhyaya edited comment on SOLR-14915 at 10/15/20, 5:40 AM:
------------------------------------------------------------------------

bq. I personally think there should be no single binary Solr distribution with 
everything thrown in. Rather, tools that are independent should just ship as 
independent binaries (with all dependencies allowing their execution). Partial 
jar subsets with links across the binary distribution will be very difficult to 
manage automatically...

+100

I envision that non essential things like this prometheus exporter should 
reside in a separate repository and have a different release cycle.
The Solr distribution should come in two flavours: slim and fat (or whatever 
nomenclature is suitable): slim one only has solr-core and solrj, fat one has 
everything that we have today. The slim one can still use all other things not 
already included using the package manager (and first party packages). And over 
time, we phase out the fat one. A 200MB download for using Solr is unacceptable 
by modern standards in a world of modularity.


was (Author: ichattopadhyaya):
bq. I personally think there should be no single binary Solr distribution with 
everything thrown in. Rather, tools that are independent should just ship as 
independent binaries (with all dependencies allowing their execution). Partial 
jar subsets with links across the binary distribution will be very difficult to 
manage automatically...

+100

I envision that non essential things like this prometheus exporter should 
reside in a separate repository and have a different release cycle.
The Solr distribution should come in two flavours: slim and fat (or whatever 
nomenclature is suitable): slim one only has solr-core and solrj, fat one has 
everything that we have today. The slim one can still use all other things not 
already included using the package manager (and first party packages).

> Prometheus-exporter should not depend on Solr-core
> --------------------------------------------------
>
>                 Key: SOLR-14915
>                 URL: https://issues.apache.org/jira/browse/SOLR-14915
>             Project: Solr
>          Issue Type: Improvement
>          Components: contrib - prometheus-exporter
>            Reporter: David Smiley
>            Assignee: David Smiley
>            Priority: Minor
>         Attachments: patch.patch
>
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> I think it's *crazy* that our Prometheus exporter depends on Solr-core -- 
> this thing is a _client_ of Solr; it does not live within Solr.  The exporter 
> ought to be fairly lean.  One consequence of this dependency is that, for 
> example, security vulnerabilities reported against Solr (e.g. Jetty) can (and 
> do, where I work) wind up being reported against this module even though 
> Prometheus isn't using Jetty.
> From my evaluation today of what's going on, it appears the crux of the 
> problem is that the prometheus exporter uses some utility mechanisms in 
> Solr-core like XmlConfig (which depends on SolrResourceLoader and the rabbit 
> hole goes deeper...) and DOMUtils (further depends on PropertiesUtil).  It 
> can easy be made to not use XmlConfig.  DOMUtils & PropertiesUtil could move 
> to SolrJ which already has lots of little dependency-free utilities needed by 
> SolrJ and Solr-core alike.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to