Adam Murdoch wrote:
>
>> I've had the need for "wiring variations" on several occasions, but
>> typically
>> not limited to a single task.
>
> I'm curious, do you have some example use cases?
>
One use case was a release workflow where the order of tasks needed to be
different for different types of builds (snapshot, release, etc.). Another
one was injecting "clean" task(s) for certain types of builds. There were
other cases.
Adam Murdoch wrote:
>
>> But true lifecycle tasks can do more. If we use them for tasks like
>> 'check'
>> and 'build', those tasks no longer appear in the command line output
>> (which
>> is good).
>
> Interesting. Why do you think that is good?
>
Because the way lifecycle tasks are currently presented in the output is
meaningless. They only appear once all work is done, don't appear if
something goes wrong, etc. To be meaningful, the output would have to be
more like that of a (hypothetical) composite task. But that raises new
questions.
Adam Murdoch wrote:
>
> I would have thought we'd want to go in the other direction: ie show less
> and less of the detail (ie worker tasks) and leave just the high-level
> stuff (ie lifecycle tasks). For example, I'd rather see:
>
> check UP-TO-DATE
>
> instead of
>
> compileJava UP-TO-DATE
> compileGroovy UP-TO-DATE
> processResources UP-TO-DATE
> compileTestJava UP-TO-DATE
> compileTestGroovy UP-TO-DATE
> processTestResources UP-TO-DATE
> test UP-TO-DATE
> checkstyleMain UP-TO-DATE
> codenarcMain UP-TO-DATE
> checkstyleTest UP-TO-DATE
> checkstyleMain UP-TO-DATE
> (lifecycle tasks classes, testClasses and check removed)
>
The up-to-date/skipped output is definitely noisy. My gut feeling is that we
should try to reduce the output in smart ways without completely abstracting
over tasks. At the end of the day, the user will still have/want to know
about tasks, for example when a task fails, runs longer, or provides some
task-specific output like number of tests completed. For this reason I also
think that we should try to keep tasks meaningful units of work from the
perspective of the build user.
Adam Murdoch wrote:
>
> We certainly want to have some way to conditionally wire up and configure
> an arbitrary set of tasks when a given task is to be executed. I'm not
> sold on using the configure block of a particular type of task. Or to
> bolting it together with 2 other behaviours.
>
> I think we should offer conditional configuration as a cross-cutting
> capability for all tasks, ideally as the default behaviour. It's a
> separate question as to whether we offer some convenience LifecycleTask
> which does some other stuff.
>
We can certainly decouple these concern. In a project I've recently
implemented the following syntax for conditional configuration:
task devBuild { ... }
task snapshotBuild { ... }
task releaseBuild { ... }
...
onlyFor(snapshotBuild, releaseBuild) { ... }
I do think conditional configuration needs to be a separate feature. The
default behavior should be lazy configuration (this will help us with many
things), which defers evaluation until first use but not necessarily until
execution time.
Cheers,
Peter
--
View this message in context:
http://gradle.1045684.n5.nabble.com/Task-Variations-tp4884963p4921004.html
Sent from the gradle-dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
