lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-2588) Make Velocity an optional dependency in SolrCore
Date Mon, 22 Aug 2011 17:45:29 GMT

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


Mime
View raw message