Hans Dockter wrote:
On Thu, Sep 13, 2012 at 10:17 AM, Rene Groeschke <[email protected]
<mailto:[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.
Havn't thought about limiting this lookup to one lookup per build yet.
But this should be possible with the planned solution.
Rene
Hans
cheers!
René
--
Principal Engineer,
Gradleware Inc. - Gradle Training, Support, Consulting
[email protected] <mailto:[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>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
