If the order of dependsOn tasks is guarantied, you open up a whole can of worms with dependencies being in the wrong/conflicting order, or the inferred order from resources being in a different order. It's just not the right direction to head. It's just serious bad times. You're swimming against the stream in Gradle if you're wanting to do this: there are other ways to accomplish the same thing without opening this can of worms.
If it's a human call, just have the person punch in both tasks at the command line. Or have one task which has the dependency, and one task which does not have the dependency. Read this thread, where I was talking about a similar kind of request: http://gradle.1045684.n5.nabble.com/Run-After-td2642739.html ~~ Robert. On Sat, Jun 18, 2011 at 10:26 AM, phil swenson <[email protected]> wrote: > well in this case it is fetching data from an external source (web > service call). There is no way to know if it's up-to-date or not, > it's a human judgement call. > > This issue would be solved if I could count on the order of > buildLanguagePackTask.dependsOn(["localeExportMessages", > "localeGenerateResources", "localeGenerateArchives"]) > > I will file a request. If gradle is going to allow me to specify > multiple dependencies, why not work in the order specified? Or is it > not that simple? > > > On Fri, Jun 17, 2011 at 6:26 PM, Peter Niederwieser <[email protected]> > wrote: >> >> phil swenson wrote: >>> >>> Maybe not, but in my case why regenerate files when I don't need to? >>> >> >> You should tell Gradle about the inputs and outputs of your tasks. Then it >> will skip up-to-date tasks automatically. >> >> -- >> Peter Niederwieser >> Principal Engineer, Gradleware >> http://gradleware.com >> Creator, Spock Framework >> http://spockframework.org >> Blog: http://pniederw.wordpress.com >> Twitter: @pniederw >> >> >> -- >> View this message in context: >> http://gradle.1045684.n5.nabble.com/bug-in-dependsOn-method-tp4500010p4500312.html >> Sent from the gradle-user mailing list archive at Nabble.com. >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
