I think one useful middle point might be to only run checks on modules that
have pending changes. Yes, as Hoss points out, an unchanged module's javadocs
might no longer work (etc.), but I don't think that's the common case.
On Dec 4, 2012, at 3:00 PM, Mark Miller <markrmil...@gmail.com> wrote:
> Well perhaps there is a middle ground - 'quasi-precommit' that just checks
> fast stuff per module… (eg doesn't build all the javadocs)
>
> Then we would catch more, but perhaps not everything.
>
> Precommit is scary slow and if it's so slow no one will use it, it's almost
> not so helpful.
>
> - Mark
>
> On Dec 4, 2012, at 11:53 AM, Chris Hostetter <hossman_luc...@fucit.org> wrote:
>
>>
>> : I'd really love to have a per-module "ant precommit".
>>
>> That's not really viable is it?
>>
>> small tweaks in one class might leave everything fine and dandy in that
>> module, but another module that depends on it could break as a result (eg:
>> removing a method/variable that is {@link}ed to, etc...)
>>
>>
>> -Hoss
>>
>> ---------------------------------------------------------------------
>> 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
