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<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. Hans > > cheers! > René > -- > Principal Engineer, > Gradleware Inc. - Gradle Training, Support, Consulting > [email protected] > http://gradleware.com > > > > > >> Hans >> >> -- >> Hans Dockter >> Founder, Gradle >> http://www.gradle.org, http://twitter.com/gradleware >> CEO, Gradleware - Gradle Training, Support, Consulting >> http://www.gradleware.com >> >> > > ------------------------------**------------------------------**--------- > To unsubscribe from this list, please visit: > > > http://xircles.codehaus.org/**manage_email<http://xircles.codehaus.org/manage_email> > > >
