lucene-dev mailing list archives

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

    [ https://issues.apache.org/jira/browse/SOLR-2588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13088929#comment-13088929
] 

Robert Muir commented on SOLR-2588:
-----------------------------------

{quote}
you lost me there ... they can use the exact same configs – that's kind of the point: testing
the exact example configs as we ship them (with <lib/> declarations that point at dirs
which may or may not contain jars depending on what contribs are built; and request handler
/ response writer declarations configured that use lazyloading to dynamic load things as needed.
{quote}

Ok: what I'm suggesting here is that core/contrib modules would still test what they do, only
I think with "minimal" configs? This way its easier to debug, e.g. conceptually lower-level
tests. But these tests still need to be realistic, e.g. include the <lib/> delcarations
you refer to?

{quote}
i mean – yes we could have tests that copy the example configs and modify them and test
that those modifications still work, but that's not really the point. the point is "core features
A,B,C should work with these example configs as is; and contrib feature X should also work
with the same example configs (unmodified) as long as contrib-X is build and in dir-X; and
contrib feature Y should also work with the same example configs (unmodified) as long as contrib-Y
is build and in dir-Y; etc..."
{quote}

Right: i see, so this 'integration' testing is a separate challenge from what I mentioned
above. In this case we want to test the example with different configurations... but if we
separate out these 'example' tests into something thats more suitable for integration testing
perhaps we can setup just an environment like this? Maybe it would mimic the core/contrib
structure in svn we have for the unit tests even... the only difference is the classpaths
etc will be different?



> 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