Dependency on task that is finalised by task.

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Dependency on task that is finalised by task.

Luke Daley-2
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


Reply | Threaded
Open this post in threaded view
|

Re: Dependency on task that is finalised by task.

Perryn Fowler


On Mon, Jan 20, 2014 at 10:25 PM, Luke Daley <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: Dependency on task that is finalised by task.

Perryn Fowler
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 <[hidden email]> wrote:


On Mon, Jan 20, 2014 at 10:25 PM, Luke Daley <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: Dependency on task that is finalised by task.

erdi
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 <[hidden email]> 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 <[hidden email]> wrote:


On Mon, Jan 20, 2014 at 10:25 PM, Luke Daley <[hidden email]> 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





Reply | Threaded
Open this post in threaded view
|

Re: Dependency on task that is finalised by task.

Daz DeBoer-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Mon, Jan 20, 2014 at 10:25 PM, Luke Daley <[hidden email]> 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






Reply | Threaded
Open this post in threaded view
|

Re: Dependency on task that is finalised by task.

Perryn Fowler
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Mon, Jan 20, 2014 at 10:25 PM, Luke Daley <[hidden email]> 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