On 03/08/2013, at 2:23, Adam Murdoch <adam.murd...@gradleware.com> wrote:
> > 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? Probably of little use in practice. We might want to be more explicit here and model it. So for a component, we can define an initial quality gate that should be passed before the component is used downstream. We could then put what we want in front of this gate, such as static analysis. Each component could have a number of gates. When you take a dependency on a component, you might say something about what type of gate it has to have passed before you will use it. This would have to be optional though as sometimes you just want to compile and don't want to wait for checks. This might be a better approach though; modelling quality gates for components (which seems inevitable anyway) and using this to optimise feedback. > >> >>> >>> 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 > > >
