Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Mon, 22 Aug 2011 17:45:29 +0000 (UTC)
From: "Hoss Man (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <40808145.1808.1314035129383.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <553123127.965.1307891703191.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (SOLR-2588) Make Velocity an optional dependency
 in SolrCore
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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