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