sorry, I meant Gant, not Grails... too many G* projects on the brain. On Fri, Aug 29, 2008 at 10:48 AM, Dennis Portello <[EMAIL PROTECTED] > wrote:
> I don't have any direct feed back for these options, though I would like to > add. Sometimes when running Corbortura or Emma, it should be run against the > entire application project and sub-projects, not on individual projects. > part of my hacked-up grails build was to have a reporting phase of the > build. > > > On Fri, Aug 29, 2008 at 10:01 AM, Hans Dockter <[EMAIL PROTECTED]> wrote: > >> I would like to start discussing how to integrate reports into Gradle. >> >> I see two kind of reports: >> >> 1.) Reports which belong to the domain of a certain task and possibly >> depend on the execution of this task. For example junit reports and >> cobertura or emma are related to the test task. >> 2.) Reports which do not belong to a certain task. For example checkstyle. >> >> How to implement 1.): >> >> a.)For any test related report task the test task may provide 2 >> properties. For example enableJunitReport and junitReport. The first is a >> boolean, the second is an instance of the JUnitReport task. But this >> instance has not been added to the project tasks yet. The test task >> registers a project.addAfterEvaluateListener(). This listener checks the >> value of for example enableJunitReports. If it is true, it adds its >> JUnitReport task instance to the project task. >> >> b.) An alternative implementation would be to for the test task, to just >> provide one property, the JUnitReport task. This task is directly added to >> the project tasks. If a user does not want it, it can be disabled, via >> setting the enabled property any task has to false. The disadvantage of this >> approach is, that the JUnitReport task is added to the task execution graph >> and makes it bigger and harder to read (e.g. by using gradle -t) without any >> purpose. Setting enabled to false just prevents that any action gets >> executed. It is the same as setting a skip property. >> >> c.) Another option is do things as in b.) but to change the behavior of >> the 'enabled' property of tasks. If a task is not enabled, it is not added >> to the task execution graph. If another task has a dependsOn relation to a >> disabled task an exception is thrown. An possibly alternative to an >> exception would be not to add the dependsOn task as well. >> >> How to implement 2.): >> We could provide a reports tasks which bundles all independent reports. It >> has the same role as the test task for test associated tasks. We have the >> same option a,b,c for implementing the association between the report task >> and its reports. >> >> >> Right now I would add the reports task to the Java plugin and we have to >> add all the necessary libs to the gradle libs folder. In another thread we >> have discussed that we want to do things differently once we have our new >> plugin system. >> >> - Hans >> >> -- >> Hans Dockter >> Gradle Project lead >> http://www.gradle.org >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> >
