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. Hans
