On Sat, Apr 2, 2011 at 11:56 AM, Niclas Hedhman <[email protected]> wrote:
> On Sat, Apr 2, 2011 at 4:22 PM, 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. > > I also agree with Peter that it is not easy topic, but the current > default is quite 'naive', and only reasonable for small builds. > > > BTW: The problem with the Ant junit aggregation is, that it does not show > > the projects involved. > > Sounds like build structure is too large if it stretches teams, but > perhaps that is just me... > I don't think so. With such a 'large' build structure you can figure out with the pre-commit build if you have broken something in projects that depend on your teams project. Google for example pushes this to the extreme by having only one source root. Hans > > - 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. > > Yes, simple ways to drive this would be really good. > > -- > 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 > > >
