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. 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. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
