[
https://issues.apache.org/jira/browse/SOLR-2588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13068611#comment-13068611
]
Hoss Man commented on SOLR-2588:
--------------------------------
bq. This is a false claim. My patch logs a warning.
my apologies, i misread the patch and thought it would only warn on first
usage. It doesn't change the fundemental issue however...
bq. Hoss, you apparently have a black or white view of things
I absolutely consider *this* issue to be black/white.
bq. However I do think that if the Solr user/packager realized that Velocity is
not used in their setup (perhaps using Solr in an embedded fashion) and if Solr
can gracefully work without it for the rest of Solr that doesn't need it, then
it should run without it.
the problem with that philosophy is that it completely breaks the "contract" we
make with our users -- novices and plugin writers -- about what they can/can't
expect to be in a basic solr installation.
if someone repackages solr to not include something that is considered a "core"
feature/dependency, then that installation is absolutely, 100% broken, and we
should not go out of our way to help that packager/installer mask the broken
nature.
It is broken not only because whatever out of the box feature we advertise as
being available no longer works for novice users who may try to use those
features, but it is broken because anyone trying to write a plugin can no
longer say "all you need to load my plugin jar is this <lib.../> directive,
because all of the dependencies are already core solr dependencies"
if VelocityWriter is a core feature (and as of now it is) then velocity is a
core dependency and we should not jump through this hoop to deal with the
possibility of velocity dependencies being missing any more then we should jump
through hoops to deal with the possibility that commons-io, or
commons-fileupload is missing -- in either case, the system is *not* a fully
functional solr installation as documented, and we should not hide that from
users until they actually try to use a documented feature and get a failure.
If someone wants to bastardize a solr installation to remove _core_
dependencies we should not be making it easier on them just because it only
means changing a few line of code -- that just hamstrings us with an
expectation that we can *never* use that dependency in any other ways in the
core. Either we rip that dependency out (making it a plugin instead of a core
feature) or we let the bastardizers patch the affected files themselves.
Any middle ground hurts our users by making it impossible to know what features
will/won't work in any given install, and hurts development by hindering
when/how we can use libraries we've already said are core dpendencies.
> Make Velocity an optional dependency in SolrCore
> ------------------------------------------------
>
> Key: SOLR-2588
> URL: https://issues.apache.org/jira/browse/SOLR-2588
> Project: Solr
> Issue Type: Wish
> Affects Versions: 3.2
> Reporter: Gunnar Wagenknecht
> Assignee: David Smiley
> Priority: Minor
> Fix For: 3.4, 4.0
>
> Attachments: SOLR-2588_Don_t_fail_if_velocity_libs_not_present_.patch
>
>
> In 1.4. it was fine to run Solr without Velocity on the classpath. However,
> in 3.2. SolrCore won't load because of a hard reference to the Velocity
> response writer in a static initializer.
> {noformat}
> ... ERROR org.apache.solr.core.CoreContainer -
> java.lang.NoClassDefFoundError: org/apache/velocity/context/Context
> at org.apache.solr.core.SolrCore.<clinit>(SolrCore.java:1447)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:463)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:316)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:207)
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
