On 13/09/2012, at 6:25 PM, Hans Dockter wrote:

> 
> 
> On Thu, Sep 13, 2012 at 10:17 AM, Rene Groeschke <[email protected]> wrote:
> Hans Dockter wrote:
> Just curious. One strong use case for remembering that a module was
> missing was to speed up the IDE tasks, e.g. when there are no src or
> javadoc jars. How would solving
> http://issues.gradle.org/browse/GRADLE-2455 affect that?
> 
> I just talked about a strategy on solving this issue with Adam.
> In general we will still keep the information that an artifact is not 
> available in a repository in the cache. We just want to ignore the 
> 'not-found' entry we had cached, if none of the repositories used in the 
> build have cached 'found'. The idea is to model that as a CachePolicy.
> 
> Normal (no src or javadoc) dependencies that are not available in any 
> repository is an edge case I think?
> 
> I wouldn't consider it an edge case. It is not the day to day behaviour for a 
> normal developer. But for anyone building up a dependency management 
> infrastructure (e.g. when migrating from an Ant build with lib dirs) it is 
> normal. Or for us working on demo set ups :) Or for ad-hoc collaboration 
> between teams when someone is expected to manually upload a dependency to be 
> shared and it hasn't been done yet. 
>  
> Is looking up the src and the javadoc task the default in our IDE tasks or 
> must it be activated?
> 
> It is the default as far as I can tell.
>  
> If it is the default, solving this issue as planned, can cause regression 
> here I think.
> 
> Would your planned fix do the new lookup multiple times per build for a 
> missing dependency or just once? As in large multi-module builds many 
> dependencies occur multiple times.

Good question. Thinking about this, we should still have an expiry time, but it 
should be short - 30 or 60 seconds. If 2 builds are running concurrently, 
there's little point in checking again if the other build checked a few seconds 
ago. Same for importing into the IDE.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

Reply via email to