THE GENERAL CASE
I agree that dependsOn should continue to require success of the
pre-requisites. I think the awkwardness is due to the fact that tasks that
perform some kind of check (like test tasks) have two levels of
success/failure:
1) the check was/was not executed successfully
2) the check itself did/did not pass
This is why we have the 'ignoreFailures' property on the Test task.
Unfortunately that only allows you to pick which level you use for the
whole build, whereas often you want different behaviour for different
follow-on tasks ( For example you want to generate test reports as long as
level 1 passes, but you don't want to build a distribution unless level 2
passed as well). Thus you often end up with the hack of a separate task to
check the second level.
Using finalizedBy in this situation *sort of* solves the 'test reports'
problem with two caveats A) you will run even if level 1 does not pass B)
you can't trigger the tests by asking for the test reports.
In any case, for now, at a bare minimum I think we should warn the user if
they have declared an incompatible combination of finalizedBy and dependsOn
rather than silently break the finalizedBy contract.
THIS CASE
The dependency between TestReport and Test was explicit to begin with, but
it was redundant as reportOn automatically adds a dependency anyway. (see
line 79 of TestReport.java)
I think in this case it probably makes sense for now to change TestReport
to automatically declare a finalizedBy relationship and document caveats A
and B above.
I'm not sure what effect this would have on the Jacoco stuff though?
Pez
On Mon, Feb 17, 2014 at 11:03 AM, Daz DeBoer
<darrell.deb...@gradleware.com>wrote:
> I'm not sure we want to water down the strict meaning of 'dependsOn':
> "A.dependsOn(B)" means that A cannot start executing until B has
> successfully completed executing. I'd rather add more kinds of dependency
> relationships if required, rather than water down this contract.
>
> In this case TestReport does not really 'dependOn' Test, since TestReport
> can run even if Test fails. It looks to me like this 'dependsOn'
> relationship is being added explicitly, not automatically via 'reportOn'.
>
> Daz
>
>
> On Sun, Feb 16, 2014 at 8:12 AM, Marcin Erdmann <marcin.erdm...@proxerd.pl
> > wrote:
>
>> This seems like a valid use case to me as well. Should we simply not skip
>> the execution of a finalizer task if its finalized task on which it also
>> depends fails? It shouldn't be hard to implement, I can have a look if you
>> guys want me to.
>>
>>
>> On Sun, Feb 16, 2014 at 11:20 AM, Perryn Fowler <
>> perryn.fow...@gradleware.com> wrote:
>>
>>> In fact, that user was trying to use a TestReport task to reportOn a
>>> Test task. Doing that automatically adds a dependency on the Test task from
>>> the TestReport task. In turn that means that Test.finalizedBy(TestReport)
>>> will not work properly.
>>>
>>> That seems unfortunate since a test report is one of the obvious use
>>> cases for finalizedBy.
>>>
>>> Perhaps TestReport.reportOn should add a finalizedBy relationship rather
>>> than a dependsOn one?
>>>
>>> In the general case is there a reason why we can/would not support
>>>
>>> task a { finalizedBy "b" }
>>> task b { dependsOn "a" }
>>>
>>> Perryn
>>>
>>>
>>> On Sun, Feb 16, 2014 at 1:20 PM, Perryn Fowler <
>>> perryn.fow...@gradleware.com> wrote:
>>>
>>>> someone else trying to do the same thing...
>>>>
>>>>
>>>> http://forums.gradle.org/gradle/topics/finalizer_task_does_not_run_if_finalized_task_fails
>>>>
>>>>
>>>>
>>>> On Mon, Jan 20, 2014 at 10:25 PM, Luke Daley <luke.da...@gradleware.com
>>>> > wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>> http://forums.gradle.org/gradle/topics/finalizer_tasks_that_depend_on_the_base_task_do_not_execute_if_the_base_task_fails
>>>>>
>>>>> task a { finalizedBy "b" }
>>>>> task b { dependsOn "a" }
>>>>>
>>>>> If a fails, b won't be executed.
>>>>>
>>>>> The use case listed in the report is something similar to the jacoco
>>>>> report task debate. The user wants "b" to be executed if "a" is in the
>>>>> task
>>>>> graph, and "a" to be executed if "b" is in the task graph.
>>>>>
>>>>> There's a case for this, but I'm having trouble finding a conceptual
>>>>> fit.
>>>>>
>>>>> --
>>>>> Luke Daley
>>>>> Principal Engineer, Gradleware
>>>>> http://gradleware.com
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>> http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
