On 03/08/2013, at 11:11 AM, Luke Daley <luke.da...@gradle.biz> wrote:
> > > On 03/08/2013, at 1:59, Adam Murdoch <adam.murd...@gradleware.com> wrote: > >> >> On 03/08/2013, at 10:32 AM, Luke Daley <luke.da...@gradleware.com> wrote: >> >>> Hi, >>> >>> It just dawned on me that shouldRunAfter() will allow us to provide a >>> better feedback experience for multi project builds. This is not a new >>> idea, but I'd not considered it for this purpose. >>> >>> I am frequently frustrated when working on multi project builds when an >>> upstream module successfully compiles, but fails a quality check. >>> >>> Say A depends on B. When I `build` my project, this happens… >>> >>> 1. compile B >>> 2. compile & check A >>> 3. check B >>> >>> If B has a checkstyle issue or a defect, I'd like to know this before >>> trying to compile A. Otherwise, I now have to change B and then recompile A. >> >> Right. >> >> Compilation of A is also a kind of quality check of B, so the order probably >> depends on the relative time it takes to compile vs the other quality >> checks. If compilation is fast and the other checks are slow, then you >> probably want to compile everything before you do the slow checks. What this >> means, I think, is that we should schedule verifications from fastest to >> slowest, regardless of where they live and regardless of whether its >> compiling or doing static analysis or what. > > That probably makes sense as a general rule. > > With a stronger component model we could push this further though by > weighting based on whether the task is a quality check of an upstream > component. So if two tasks are otherwise 'equal', then prefer the quality checks of a component over usages of that component? > >> >> Another solution to the above problem is to make compilation incremental wrt >> the API of its dependencies. Often, a fix for quality check failure in B >> does not affect its API (eg unused import or some missing javadoc or missing >> test coverage or whatever) so if A has already been compiled we can skip its >> compilation, even if the implementation of B has changed. This also helps >> for many other situations. > > These two things are complimentary. Absolutely. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
