Hi Mathias, thanks for pointing this out.
Done! Cheers Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleware CEO, Gradleware - Gradle Training, Support, Consulting http://www.gradleware.com On Wed, Mar 2, 2011 at 4:18 PM, Mathias Kalb <[email protected]>wrote: > Hi, > > please change the version of this JIRA issues: > http://jira.codehaus.org/browse/GRADLE-1333 > http://jira.codehaus.org/browse/GRADLE-320 > > regards, > Mathias Kalb > > Am 02.03.2011 11:07, schrieb Hans Dockter: > > We are working together with the people from JFrog on improving the >> Ivy/Gradle dependency cache. There is a lot of cool stuff we want to add. In >> this posting I want to discuss a particular aspect. We are very interested >> in feedback and good use cases therefore I'm posting this to the user list >> and not to the dev list. >> >> Current State: >> >> - Ivy dynamic revisions, like "junit:junit:4.+" can be used in Gradle. Ivy >> enables to set a time to live (ttl) for the cached dependency. During that >> time, Ivy does not check for newer versions of the dependency. We don’t >> expose this Ivy feature yet via Gradle. >> >> - Maven snapshots: Although Ivy can resolve from Maven repositories and >> understand Maven snapshots, it does not expose its ttl mechanism to Maven >> snapshots. Which means that with plain Ivy there is for each run of a build >> a remote check whether a newer version of the snapshot exists. The >> performance hit is extreme, specially if your repository is in the internet. >> Gradle provides therefore the possibility to configure the actual Maven >> resolver for how often to look for a newer version. >> >> - Offline: Neither Ivy nor Gradle does provide build-in offline support. >> The workaround is to add an additional offline resolver that is using the >> cache as a repository. >> >> Planned for milestone-2: >> >> 1. We want to add build-in offline support. >> >> 2. We want to have a better and more consistent model for dynamic >> revisions, including Maven snapshots. A simple solution would be to use >> offline support for this. We could just add a timer schema for offline >> builds. To make things fully flexible without making them complicated, we >> could also add a hook where you can add code that decides per dependency >> whether the offline cache should be used. >> >> 3. Alternatively we could add either to the cache or to all repositories a >> way to define ttl’s for dependencies. I’m not sure whether this should be a >> property of the cache or the resolver. In Maven it is a repository property, >> in Ivy a property of the cache. Although in Ivy to can even add a cache >> instance per resolver if you like. >> >> As we are not sure about all the use cases yet I favor approach No. 2. It >> is very simple and yet you can deal with all custom scenarios via the hook. >> I would guess that those custom scenarios are the exception and that for >> most users a ttl for the offline build is good enough. >> >> 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 > > >
