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

Reply via email to