For "Only testing downstream dependencies" you will have a challenge, since tests are often involving Reflection (via Spring for instance), and it might become hard for people to set this up correctly.
In the "performance space", I would like to suggest that you add some type of 'profiler' that can collect statistics for you (perhaps optionally) and have people send back those to you for analysis. I know, for instance, that what our projects suffer from at work are completely different from what my open source projects suffer from. And you should probably get yourself a better/wider view of what is really going on "out there" in real numbers, rather than benchmarking and sampling a few select projects. Cheers Niclas On Fri, Dec 27, 2013 at 5:55 AM, Adam Murdoch <adam.murd...@gradleware.com>wrote: > > On 24 Dec 2013, at 6:12 pm, Hans Dockter <hans.dock...@gradleware.com> > wrote: > > > On Saturday, December 21, 2013, Luke Daley wrote: > > <snip> > >> >> I'm pretty dubious about all of this. Looks to me like a difficult thing >> to pull off outside of the compiler. I'm sure we can get something working, >> but whether it's reliable enough and fast enough is another question >> (hopefully answered by the spike). I also wonder whether investing into >> more fine grained parallelism and coarser avoidance (e.g. ignoring non >> visible classpath changes) wouldn't be more fruitful and more generally >> applicable. >> > > There are very different scenarios where this is helpful. > > - There are some large Gradle installations out there with massive single > source trees with compile times of 2 minutes and more. > - You have to see this also in the context of our upcoming continuous mode > and deeper IDE integration where on the one hand Gradle compile is used > with high frequency and on the other hand we don't have to scan the > filesystem and we can keep the graph in memory. > > Last but not least it is long overdue that we need to have this graph > available also for other important functionality: > > - Unused elements in the classpath > - Enforcing API compatibility between modules > - Incremental Testing > - A lot of other interesting analytics tasks > > > - real conflict detection > - some interesting api-implementation separation options > - better handling for some interesting ways of structuring code, such as > all source files in the same physical source directory, while keeping > separation between the logically separate things. > - possibly what you meant by ‘analytics tasks’, but this allows us to > answer questions such as ‘which other teams use this method and where?’ or > do things like ‘test only the downstream dependencies that are affected by > this change’. > > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > > > > -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug