On Sunday, December 29, 2013, Niclas Hedhman wrote:
>
> 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.
>
That is something we are working on.
>
> 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.
>
I agree. That would make a lot of sense.
Hans
>
>
> Cheers
> Niclas
>
>
> On Fri, Dec 27, 2013 at 5:55 AM, Adam Murdoch
> <adam.murd...@gradleware.com<javascript:_e({}, 'cvml',
> 'adam.murd...@gradleware.com');>
> > wrote:
>
>>
>> On 24 Dec 2013, at 6:12 pm, Hans Dockter
>> <hans.dock...@gradleware.com<javascript:_e({}, 'cvml',
>> '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
>
