+1 for aggregating tasks. I think that code coverage reports are another excellent candidate for aggregating across projects.
Sean On Sat, Apr 2, 2011 at 9:22 AM, Hans Dockter <[email protected]>wrote: > Hi Niclas, > > I definitely see your points. We are talking about making the concept of > aggregating task a first class concept in Gradle for quite a while but > haven't had a chance to tackle this yet. > > I'm usually also almost interested in the aggregate report for junit and > even more so for javadoc. > > BTW: The problem with the Ant junit aggregation is, that it does not show > the projects involved. Any report that does not group by project (I don't > mean javadoc here) is a problem with larger multi-project builds. They are > often across teams. When you only have packages this makes it hard to figure > out responsibilities. > > I can see that the way you want to setup things makes a lot of sense for > many projects. But I guess there are many different use cases out there (as > Peter pointed out in the other mail). I think what we really need is an easy > way to model them all. > > - Every build-in report for Gradle should be aggregation aware where it > makes sense and be able to create aggregate reports. > - Language elements that make it easy to express that you want for a task > either just aggregation, or only per-subproject or both. > > Hans > > On Sat, Apr 2, 2011 at 4:53 AM, Niclas Hedhman <[email protected]> wrote: > >> Gang, >> >> Half my build script is related to the fact that I find it highly >> annoying that reports are created "per project" instead of aggregated >> to one single point, i.e. the rootProject. And this goes (in my case >> at least) for all reports I am interested in, incl Javadoc which I >> also consider a kind of report. >> >> I would like to get a little bit of feedback from others whether it >> makes sense to make this the default; >> >> * If built from rootProject --> only generate aggregated reports, and >> no reports in the sub-projects. >> * If built from childProject --> only generate a childProject-local >> report and don't mess with the top level one. >> * For projects with children (parentProjects?), I guess the report >> should be aggregated at that level. >> >> Which means that for "any build", reports are aggregated to the >> `pwd`/<reportsDir> only, which is predictable and flexible. >> >> WDYT? >> >> >> Cheers >> -- >> Niclas Hedhman, Software Developer >> http://www.qi4j.org - New Energy for Java >> >> I live here; http://tinyurl.com/3xugrbk >> I work here; http://tinyurl.com/24svnvk >> I relax here; http://tinyurl.com/2cgsug >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> >
