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.
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.
Another way of saying this is why should I have to remember to type
dashes? What is the advantage to the end user of this:
gradle --refresh-dependencies --no-color --info --daemon jar
versus this:
gradle refreshDependencies noColor info daemon jar
What does the "--" actually add to the user experience other than
extra typing? Maybe these type of things should be just subtasks of a
gradle SystemTask. Then you can always run prior to any user/plugin
level tasks?
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.
Gradle is about the greatest thing since sliced bread, but command
line arguments are so last century!
:)
Philip
PS ...feeling very embarrassed that I actually used the word "paradigm".
On Fri, Mar 2, 2012 at 9:34 AM, Luke Daley <[email protected]> wrote:
>
> On 02/03/2012, at 2:20 PM, Philip Crotwell wrote:
>
>> Is there a reason why these are command line args and not tasks?
>
> Generally because they are cross cutting, and not independent pieces of work
> to be done.
>
> That is, they alter Gradle's behaviour in a kind of global way.
>
>> Personally I would rather say "gradle refreshDependencies" as trying
>> to remember which things need to be prefixed with double dashes seems
>> a pointless distinction from an end user perspective. I guess there
>> are some things that only make sense as CLI "dash" args, but it seems
>> to me that if something can be expressed as a task, it should be. That
>> allows all of these things to participate fully in the task ecosystem
>> instead of being a separate external beast. Suppose I wanted to write
>> a task that did something when the dependencies were refreshed. It
>> would be trivial if refreshDependencies was a task, but maybe
>> impossible if it is only in the CLI.
>
> Dependency resolution is not atomic, and is done on demand.
>
> What you are describing would require introducing something that resolved all
> of the dependencies for a project.
>
> --
> Luke Daley
> Principal Engineer, Gradleware
> http://gradleware.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
