On 03/01/2012, at 8:12 AM, Daz DeBoer wrote: > Hey all > > Currently, if you want to be guaranteed of getting the very latest SNAPSHOT > for your build, you need to use: > configuration.name.resolutionStrategy.cacheChangingModulesFor 0, 'seconds' > > This has the unfortunate side-effect of causing every sub-project in a > multi-project build to verify and possibly download the SNAPSHOT artifact. So > if you have 100 subprojects, every one will make a remote call to check if > the SNAPSHOT is up-to-date, and if no SHA1 file is available to check, you'll > download the SNAPSHOT artifact 100 times!
We also have the same side-effect for dynamic versions (except the responses are usually smaller, being directory listings and maven-metadata.xml and so on). > > It's trivial for me to update Gradle to only resolve a SNAPSHOT once per > build, using the cached artifact for the lifetime of the build. The main > downside to this is that we would no longer support the scenario > multi-project scenario: > /sub-project1 -- Resolve mymodule-SNAPSHOT > /sub-project1 -- Publish a new version of mymodule-SNAPSHOT > /sub-project2 -- Resolve mymodule-SNAPSHOT, and expect the newly published one > > I guess we could support this by invalidating the cached entry when we > publish a new version, but what if the publication is done via a custom task? > Perhaps we need a new way to express that a module may change _during_ the > build, so we can't even rely on a cached version from within this build. My > gut feel is that the common scenario is to use the latest version, but only > check once per build. I think we should check dynamic versions and changing artifacts once per build, and wait for a real use case to drive anything else (eg I could see build pipelining or incremental publication needing some of this stuff). The only work I would do towards handling the above scenario is to give the user some way to provide a custom caching policy, so that they can implement the above logic if they need to. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
