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-2303) remove unnecessary (and problematic) log4j jars in contribs
Date Tue, 18 Jan 2011 20:42:43 GMT

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

Robert Muir commented on SOLR-2303:
-----------------------------------

bq. OK, scratch the notion of removing the junit-4.7.jar file from Solr, the test cases...er...stop
compiling. But the rest still stands.

{quote}
<pathelement path="${common-solr.dir}/../lucene/lib/ant-junit-1.7.1.jar" />
<pathelement path="${common-solr.dir}/../lucene/lib/ant-1.7.1.jar" />
<pathelement path="${common-solr.dir}/../lucene/lib/junit-4.7.jar" />

in place of java.class.path and all is well. Is this the path you'd go down? I'm not very
comfortable having Solr reach over into Lucene, but what do I know?
{quote}


Yeah, in general it would be good to explicitly include ant, ant-junit, and junit into our
classpath for tests.
I know i fooled with trying to do this across all of lucene and solr, there are some twists:
* when the clover build is enabled, we have to actually use the ant runtime/java.class.path,
because clover injects itself via ant's classpath via -lib. There
might be a better way to configure clover to avoid this, but failing that we have to "sometimes"
support throwing ant's classpath into the classpath like we do now.
* the contrib/ant gets tricky (i dont remember why) especially with clover enabled :)
* finally, ant 1.8 support might break, since we specifically include ant 1.7 stuff in our
lib. But its generally what we want, better to have a reliable classpath in
our build/tests than to compile/test with "whatever version of ant the person happens to be
using". Ant gets angry if you try to put ant 1.7.jar into an ant 1.8 runtime...

the same situation exists for compilation actually, but I *think* i fixed that one... you
would have to re-check :)


> remove unnecessary (and problematic) log4j jars in contribs
> -----------------------------------------------------------
>
>                 Key: SOLR-2303
>                 URL: https://issues.apache.org/jira/browse/SOLR-2303
>             Project: Solr
>          Issue Type: Improvement
>          Components: Build
>            Reporter: Robert Muir
>            Assignee: Erick Erickson
>             Fix For: 4.0
>
>         Attachments: SOLR-2303.patch
>
>
> In solr 4.0 there is log4j-over-slf4j.
> But if you have log4j jars also in the classpath (e.g. contrib/extraction, contrib/clustering)
you can get strange errors such as:
> java.lang.NoSuchMethodError: org.apache.log4j.Logger.setAdditivity(Z)V
> So I think we should remove the log4j jars in these contribs, all tests pass with them
removed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message