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 > > >
