[
https://issues.apache.org/jira/browse/SOLR-2588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13088842#comment-13088842
]
Hoss Man commented on SOLR-2588:
--------------------------------
bq. Ugh, this got more complicated thanks to core tests relying on the example
config. Running on a clean (ant clean) trunk, tests that rely on the example
solrconfig.xml fail because the Velocity contrib JAR isn't built yet. I guess
the other contribs don't fail because their componentry is lazy loaded but
response writers aren't.
there's two aspects of this to worry about, it's not really clear to me if only
one/both apply here...
1) testing the contrib. if the majority of the tests that exist for the
velocity writer are dependent on using the example, then those relaly need to
be refactored into the contrib (if that's where the code is going)
2) testing the example. the was the original point of those tests -- to verify
that when users try to use the example, it will owrk (many tests have start
abusing those configs unneccessarily, but that's the original point) ...
#2 is a lot harder to find a "good" solution for. on the one hand, adding a
lazyload option to response writers gets us out of the dependency whole of
testing the example w/o the velocity writer being built; but it side steps the
true goal of saying "will the example work". It seems like the three possible
solutions are:
a) ignore the problem
b) use lazyloading; leave the "core" example tests only testing "core" things;
add a velocity contrib test that *also* tests the example this time explicitly
excersizing the velocity writer and testing that that piece of the example
configs works
c) refactor all of the example tests into a new contrib/module/whatever that
depends on all of hte contribs.
either B or C seem like the best long term approach, and would also be a
pattern that could be applied to the other contribs used in the example via
lazy loading. B feels dirtier, but might actually be the wisest choice since
it would help us test more permutations (a user tries the example with only the
core solr stuff, a user tries the example adding velocity plugin, etc..)
> 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: Erik Hatcher
> Priority: Minor
> Fix For: 3.4, 4.0
>
> Attachments: SOLR-2588.patch, SOLR-2588.patch, SOLR-2588.patch,
> SOLR-2588.patch, SOLR-2588.patch,
> 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
