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
