lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-3259) Solr 4 aesthetics
Date Wed, 21 Mar 2012 01:24:37 GMT

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message