: Ignoring the JSP dilemma... DIH's JAR doesn't need to be in the WAR, but can : ship in a lib/ directory outside the WAR and come in as a plugin. And Solr : can ship with all of the contribs wired in to a kitchen-sink example : configuration. : : There is merit to keeping Solr's WAR and core to the most minimal size : possible and leveraging the plugin capability to let users reduce the : footprint and un-used parts.
+1 ... there really shouldn't be any contrib's in the war. If we're worried that asking people to put the DIH jar in the plugin directory is too complicated for new users to understand (and i really can't believe that: if someone can understand ow to write a data-config.xml then copying a jar file should be trivial) we can make a "solr-kitchen-sink.war" that contains *every* contrib and *every* dependency in addition to the regular one. But even that seems less useful in general then having a more robust set of examples -- where each one gets a lib directory populated with just the plugins it's demonstrating (and possibly a "kitchen-sink" example showing off all of them) Honestly: I didn't even realize DIH was adding itself to the war untill recently, but then again i've been a little out of touch. As for the JSP issue: personally, I think ideally we'd eliminate the JSPs completley (regardless of wether they are in a contrib or not). Almost every admin JSP we have now could be done as request handler with an XSLT directive for the browser to apply (which gives us hte added bonus of making the data on all those pages easily machine parsable), but if "contribA" has need of some particularly complex server side presentation processing then making contribA depend on the velocity contrib seems like the best way to go. -Hoss
