i don't think it should be fixed in a one-off way honestly. Instead I think the test should instead be either removed, or fixed to not carry this stuff around (comparing actual vs expected with assertArrayEquals, so that it'd currently fail in its state of having leftover trash).
Currently, i don't understand the value that this test brings. it seems to just artificially increase the amount of work you have to do, to add a new getter/setter, but not in fact test anything. On Fri, Sep 1, 2017 at 4:30 PM, Erick Erickson <[email protected]> wrote: > Do you see any harm in removing this sole remnant from master and all > the references in 7x? AFAICT, writeLockTimeout is never _used_ in 7x > so is just confusing to no real good. > > > > On Fri, Sep 1, 2017 at 12:16 PM, Robert Muir <[email protected]> wrote: >> that is just some leftover in a test that didn't get removed when the >> deprecations were ultimately removed. >> >> On Fri, Sep 1, 2017 at 3:12 PM, Erick Erickson <[email protected]> >> wrote: >>> Particularly a question for Robert Muir: >>> >>> https://issues.apache.org/jira/browse/LUCENE-6525: Deprecate >>> IndexWriterConfig's write lock timeout >>> >>> Eventually most all traces were removed, but TestIndexWriterConfig has: >>> >>> getters.add("getWriteLockTimeout"); >>> >>> even in master, plus 7x has a number of references to >>> writeLockTimeout. Should all those be removed too? >>> >>> Best, >>> Erick >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
