On 04/02/2013, at 9:36 AM, Hans Dockter wrote: > > > On Sun, Feb 3, 2013 at 8:59 PM, Adam Murdoch <[email protected]> > wrote: > > On 03/02/2013, at 9:02 PM, Hans Dockter wrote: > >> >> >> On Sat, Feb 2, 2013 at 11:50 PM, Adam Murdoch <[email protected]> >> wrote: >> Hi, >> >> Something I'd like to try to achieve as part of the work to introduce >> multiple outputs for JVM based projects, is to create fewer task instances >> at configuration time. There are 2 main parts to this: >> >> 1. Don't create tasks that will never be required. For example, if there is >> no src/main/resources directory, and nothing generates it, then don't create >> a processResources task. >> 2. Don't create tasks that are not required for the current build. For >> example, if I'm generating the javadoc, don't create the test task or any of >> its dependencies. >> >> Ignore for the moment how we might do this. Let's just say its possible to >> infer both #1 and #2. >> >> Which would be awesome. But doesn't it leave the door open for certain >> undetectable(?) configuration time dependencies? I would say if we are able >> to reliably solve that problem, reliable parallel task execution isn't far >> away either (if we want to go for it). > > Possibly. We'd be inferring whether a thing is required, but not how it is > used, so we wouldn't know whether its safe to run it concurrently with other > tasks. I imagine we could tweak things to allow us to figure this out. > > My above comment doesn't make much sense. What does make sense though I think > is: > > For smart task creation we need to know the configuration time dependencies > between tasks, e.g.: > > task foo { > bar = jar.archivePath > } > > If we know them, we can do parallel task configuration.
I think using rules to infer the what and the how will give us some opportunities to make this work. If a 'how' or a 'what' rule only has access to a read-only immutable view of the inputs for a build item, then we can potentially fire the rules for different things in isolated contexts and configure and build them in parallel. It's basically taking the decoupled projects model and pushing it down the next level to decoupled build items, so that you get parallelism and distribution at the build item level. If you want finer-grained parallelism, then make your build items finer-grained. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
