Re: Suppressing list doesn't take effect when -Dtests.postingsformat is used

2012-06-03 Thread Dawid Weiss
Robert's patch looks good to me. Perhaps we could just move the entire assumption to that rule (I don't have the code open so I don't know where this is called, but I think it should be determined as soon as possible and once). Dawid On Sun, Jun 3, 2012 at 9:54 AM, Uwe Schindler wrote: >> The ac

RE: Suppressing list doesn't take effect when -Dtests.postingsformat is used

2012-06-03 Thread Uwe Schindler
> The actual source of the problem is that suppression applies to codec.getName > and enforcing a TEST_POSTINGSFORMAT means Lucene40Codec is created > which always returns Lucene40 from getName(). A simple fix would be to allow > changing the returned name for Lucene40. I don't think we should do

Re: Suppressing list doesn't take effect when -Dtests.postingsformat is used

2012-06-03 Thread Robert Muir
On Sat, Jun 2, 2012 at 11:16 PM, Dawid Weiss wrote: > The actual source of the problem is that suppression applies to > codec.getName and enforcing a TEST_POSTINGSFORMAT means  Lucene40Codec > is created which always returns Lucene40 from getName(). A simple fix > would be to allow changing the re

Re: Suppressing list doesn't take effect when -Dtests.postingsformat is used

2012-06-02 Thread Han Jiang
Thank you David, currently I just manually remove those testcases when doing tests... Hmm, seems that getName() is not allowed to override, then can we make use of "toString()" to record the information? When judging whether a codec is to be suppressed, check getName() first, and if it matches 'Lu

Re: Suppressing list doesn't take effect when -Dtests.postingsformat is used

2012-06-02 Thread Dawid Weiss
The actual source of the problem is that suppression applies to codec.getName and enforcing a TEST_POSTINGSFORMAT means Lucene40Codec is created which always returns Lucene40 from getName(). A simple fix would be to allow changing the returned name for Lucene40. Alternatively, we can do suppressio