Ok, that quick fix I thought would work -- it won't. I'll fix it properly (or rather hack around intellij problems) in LUCENE-4054.
Dawid On Wed, May 16, 2012 at 12:51 AM, Steven A Rowe <sar...@syr.edu> wrote: > Thanks, Dawid > > The result is strange - a red (X) still appears next to this test, but the > overall result bar stays green, and the same exception gets printed out. > > Here's a screen grab showing this: <http://i46.tinypic.com/syknja.png> > >> (unless you know of a way to restrict it to Test* classes) > > Combining all-tests-in-module with name restrictions isn't possible in any > released version of IntelliJ, but it should be possible in the next release: > <http://youtrack.jetbrains.com/issue/IDEA-84037> > > Steve > > -----Original Message----- > From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid > Weiss > Sent: Tuesday, May 15, 2012 5:49 PM > To: dev@lucene.apache.org > Subject: Re: Clean-jars. > > Ok, it should work with intellij now (didn't check though). These nested > classes will still be run by intellij runner (unless you know of a way to > restrict it to Test* classes) but will be ignored. > > Dawid > > On Tue, May 15, 2012 at 11:27 PM, Dawid Weiss <dawid.we...@cs.put.poznan.pl> > wrote: >>> After updating, I ran through all of the module test run configurations on >>> IntelliJ, and one test failed: >> >> Eh. This one is again a test that normally shouldn't be included in >> the suite (nested class). It is meant to fail because it's actually >> testing that assertion in LuceneTestCase... I'll see what I can do. >> >> Dawid >> >>> >>> -------- >>> java.lang.RuntimeException: There are overridden methods annotated with >>> org.junit.Before. These methods would not be executed by JUnit and need to >>> manually chain themselves which can lead to maintenance problems. Consider >>> using different method names or make hook methods private. >>> Method: public void >>> org.apache.lucene.util.junitcompat.TestBeforeAfterOverrides$Before1.b >>> efore()#before[] possibly overriden by public void >>> org.apache.lucene.util.junitcompat.TestBeforeAfterOverrides$Before3.b >>> efore()#before[] >>> at >>> org.apache.lucene.util.ValidateNoInstanceHooksOverrides.checkNoShadow >>> s(ValidateNoInstanceHooksOverrides.java:68) >>> at >>> org.apache.lucene.util.ValidateNoInstanceHooksOverrides.validate(Vali >>> dateNoInstanceHooksOverrides.java:45) >>> at >>> com.carrotsearch.randomizedtesting.RandomizedRunner.runCustomValidato >>> rs(RandomizedRunner.java:1357) >>> at >>> com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(Randomiz >>> edRunner.java:595) >>> at >>> com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(Random >>> izedRunner.java:132) >>> at >>> com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedR >>> unner.java:551) >>> -------- >>> >>> Steve >>> >>> -----Original Message----- >>> From: Dawid Weiss [mailto:dawid.we...@gmail.com] >>> Sent: Tuesday, May 15, 2012 2:57 PM >>> To: dev@lucene.apache.org >>> Subject: Clean-jars. >>> >>> I've updated a jar dependency version -- you need to: >>> >>> ant clean-jars resolve >>> >>> Does anybody have anything against it if I make 'ant eclipse' depend on >>> 'clean-jars resolve' sequence? I am also tempted to make ant clean perform >>> a cleanup of jar files since anything else (ant test, etc.) does a resolve >>> anyway... >>> >>> Dawid >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For >>> additional commands, e-mail: dev-h...@lucene.apache.org >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
