This would be quite interesting. I don't think we can roll it out in 1.x as a default and just document the potential breakages. I vote for an option that keeps backwards compatibility.
Cheers! On Sun, Feb 3, 2013 at 11:36 PM, Hans Dockter <[email protected]> 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. > > Hans > -- Szczepan Faber Principal engineer@gradleware Lead@mockito --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
