[
https://issues.apache.org/jira/browse/SOLR-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234012#comment-13234012
]
Hoss Man commented on SOLR-3259:
--------------------------------
bq. the concept of an "example" server that you must configure yourself has
become less than ideal... perhaps we should just create a "server" directory
(but leave things like exampledocs under example)
bq. Would also be nice to remove the "multicore" directory in there (since the
normal server is already multi-core enabled). Of course if we moved just the
essential parts to "server", then "multicore", "example-DIH" and "exampledocs"
would all be left behind in "example", as they should be.
once upon a time, i argued heavily that we should renamed "example" to
"examples" and have many more of them ("minimal", "tech-products-from-the-90s",
"books", "kitchen-sink", "multicore", "dih", etc...) .. and the only reason i
never pushed harder for this was because that kind of directory structure would
have made running the "main" example (whatever we might have called it) much
harder then "java -jar start.jar" because it would have required specifying
solr.solr.home.
Thinking about it some more now that you've brought this issue up, it occurs to
me that in that intervening time, multicore solr setups have been come the
norm, not the exception ... so i'm now much more on board the idea of having a
single example setup -- even calling it "server" if people think that's a good
idea -- provided we move all of the various examples we have into that example
setup as multiple cores.
they don't have to all be enabled, they don't even have to be commented out in
solr.xml, it would just be nice if they lived in the same directory and could
easily be added as new cores with a simple CREATE commands a relative paths.
So by default if you did "cd server && java -jar start.jar" you might only get
one collection (or maybe two if we also want to show off a "minimal"
collection) but the docs for features like DIH might say "to see an example of
this, hit the following URL to create a new collection using the DIH configs:
http://localhost...CREATE";
bq. If anything I'd vote for making the distro closer to what people would want
in production. You could then have a pure "solr/jetty" folder with ONLY jetty,
a "solr/example-home" folder which holds todays "example/solr" ...
start-solr.[cmd|sh], which copies the war from dist to jetty/webapps, sets
-Dsolr.solr.home and starts Jetty
while i like the idea of creating clearer/cleaner separation between what files
are "jetty" and what files are "solr" and what files are "config" i'm not a fan
of your specific suggestions here because it moves away from the really clean
simplicity of "cd something && java -jar start.jar" -- which make it *really*
trivial for anyone anywhere to try solr out regardless of their os, or what
weird eccentricities are in their shell, or whether the file perms on some
scripts are correct, etc...
if we want to start shipping init.d scripts and what not for "production usage"
(something we typically avoided in the past because there are so many different
ways people like to do these things, not to mention that many people like to
use tomcat or some other servlet container) then that seems like it
could/should really be distinct from how people run the example for the
tutorial ... it shouldn't be completely orthogonal, we should be able to say
something like: "if you copy this ./server/ directory to some place on your
production server, this directory of ./service-tools/ can be used to
automatically start/stop when your machine comes up or down, just configure the
path where you copied ./server/" ... but people shouldn't have to use some
start.sh just to try out the tutorial not compared to how easy "java -jar
start.jar" is today.
> Solr 4 aesthetics
> -----------------
>
> Key: SOLR-3259
> URL: https://issues.apache.org/jira/browse/SOLR-3259
> Project: Solr
> Issue Type: New Feature
> Reporter: Yonik Seeley
> Fix For: 4.0
>
>
> Solr 4 will be a huge new release... we should take this opportunity to
> improve the out-of-the-box experience.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
