On 03/02/2013, at 10: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. We'd be in the business of requiring users to write thread safe build scripts (or at least sections thereof), which we have previously stated was too much to ask of users. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
