On 2 March 2012 09:08, Philip Crotwell <[email protected]> wrote: > OK, but "refreshDependencies" seems to be no more cross cutting or > global to me than "clean" or "tasks" or even "dependencyReport". > Perhaps it needs to run very early in the build, just like clean, but > gradle can handle that. And perhaps under the hood it is special in > how it interacts with the core. But from an end user perspective, I > just don't see the qualitative difference. >
At the moment '--refresh-dependencies' is not an action, like 'clean' but more of a mode like '--info'. As in, it tells Gradle to bypass the cache when resolving dependencies, it doesn't do anything on it's own. If no dependencies are resolved during a build, '--refresh-dependencies' has no effect. > I think you also could make a case that things like "daemon", "help", > "offline" and "version" could also be made into tasks. In fact I would > almost say that if you can do it from the command line, and it doesn't > require a second parameter, you should also be able to do it with a > task. > <snip> > > In general, it just seems to me that with a system as amazingly > dynamic and powerful as gradle, you should push as much of the > configuration and execution into the normal buildfile plus task > paradigm as possible. > I'm not sure these should be tasks, but they should certainly be accessible in the DSL. This is our plan and we're working on it. You will be able to create a task that manipulates these things via the DSL, without them becoming 'built-in tasks'. cheers Daz
