Have you investigated the impact of using a cache timeout of, say, 1 hour? Would this slow things down too much? The extra directory listing time may not be significant. Daz
On Wed, Aug 13, 2014 at 4:44 PM, Lóránt Pintér <lorant.pin...@prezi.com> wrote: > Hi, > > Most of our builds depend on dynamic versions of internal plugins that > come from our internal Artifactory. This way we can easily update builds > without having to change many repos, and it’s all very nice. Except for > caching. > > The default cache timeout of 24 hours is messing with us a lot. It means > that if I deploy a new version of an internal plugin, some people will get > the update sometime later today, others only tomorrow. So I need to be on > alert for the whole 24 hours to see if there was a problem, or ask everyone > (there’s always somebody not listening) to run a build with > --refresh-dependencies. > > It would make a lot more sense to me if the cache could be set to expire > at a certain point in time, say, the next time the clock hits 5AM, so > everybody would get the update in the morning. > > I can do this with the current tools by calculating the number of seconds > until the next 5AM, but it looks weird. > > I was wondering if there was some best practice on how to do this better. > Or if this is a good approach, would it make sense to have some DSL in > Gradle to express “cache until 5AM” more easily? > > Thanks. > > -- > > *Lóránt Pintér* > > Developer at Prezi <http://prezi.com> > -- Darrell (Daz) DeBoer http://www.gradleware.com
