: 2) i'm vaguely familiar with debian policy on "no redundency" but i'm not : sure it relaly applies here ... the published releases of Solr only : include one jar: the solr.jar (which contains solr source code for use in
whoops ... my bad, i forgot we do actually include all of the other jars in the "lib" directory of the release ball for users compiling plugins, but they aren't used by a running instance of solr.war (it has copies of them embedded in it) and can easily be excluded from a downstream package. all of my other comments are still very applicable however.. : compiling plugins). other jars are bundled into the solr.war which should : be considered a single "binary" entity ... much like a C app might link in : a bunch of independently compiled object files. attempting to : "extract" those jars from the solr.war and reuse other jars installed by : other packages is like trying to unlink that C program and make it use : shared object files instead --- it's a pretty big leap. : : 3) Some of the jars Solr inlcudes in it's war are not the officially : released version of third party software. We frequently use development : versions (varefully noting which version in our README) when we feel they : are stable enough and provide important features. For this reason, you : may find it hard to achieve your goal in a forward maintainable manner no : matter what. -Hoss
