>gradle refreshDependencies noColor info daemon jar So refreshDependencies and noColor runs with lifecycle log level but daemon and jar with 'info'? And the refreshDependencies runs in the process VS jar that deserves a daemon? The task concept is cool but what you suggest is a bit of a stretch to me :) Thanks for feedback, though.
Cheers! On Fri, Mar 2, 2012 at 5:08 PM, 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. > > 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 > > > -- Szczepan Faber Principal engineer@gradleware Lead@mockito
